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ABSTRACT 


Previous research has shown that it is possible to use the Internet’s Multicast 
Backbone (MBone) and associated audio/video software for the purpose of Distance 
Learning. As more education is performed online, the need arises to be able to view the 
content at the user’s convenience. Through experimental testing, this thesis investigates 
the usefulness and feasibility of applying networked recording and storage of digitized 
audio and video, all via the MBone for distance learning. 

Large distributed organizations such as the Naval Service can economically benefit 
from the use of the Multicast Backbone and its associated tools. To date. Navy and 
Marine Corps projects using video teleconferencing have not exploited the vast 
possibilities provided by the Internet and the MBone. This thesis takes distance learning 
one step farther and combines MBone audio/video vwth the new recording tool called the 
Multicast Backbone Video Conference Recorder (MBone VCR). This enables distance 
learning as a viable replacement to on-site training. It is technically feasible and 
economically supportable to record the digital media that results from an MBone session 
used for a distance learning program. That stored information can then be used repeatedly 
and easily updated to support changing curricula and information. Problems and network- 
accessible solutions are demonstrated in this case study on use of the MBone VCR as a 
usable remote educational tool. 
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I. INTRODUCTION AND MOTIVATION 


This thesis investigates the usefulness and feasibility of applying networked storage 
of digitized audio and video, all via the Multicast Backbone (MBone) for distance 
learning. The research follows the “Recommendations for Future Work” section of the 
thesis “Internetworking: Worldwide Multicast of the Hamming Lectures for Distance 
Learning” (Emswiler, 1995). 

A. BACKGROUND 

The idea of face-to-face meetings without the need for travel has intrigued 
educators and business leaders for years. Science-fiction television dating back to the 
1960's has portrayed the future as one in which people will routinely communicate over 
great distances using audio and video. Distance education has recently been considered in 
much the same way. With impressive advances in data compression, real-time transport 
protocols and transmission media, the future seems to have arrived. Today people across 
the globe can come together using the Internet and effective audio/video software tools 
that utilize a virtual network called the Multicast Backbone (MBone). 

The MBone uses audio-visual conferencing capabilities that were developed to 
provide scientists with an easy way of sharing information over long distances in a manner 
similar to their normal interactions—and in their normal workplaces. The MBone was also 
developed to prove the potential usefulness of this kind of interaction on a scale provided 
by the Internet. The MBone effort has effectively helped set standards that can guide 
interoperable software development (Davies, 1995). 
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Since it began, the MBone has proven to be an important tool in remote 
conferencing. However, most of the events last one day or perhaps a week and are not 
broadcast on a regular production basis. In the first quarter of 1995, Tracey Emswiler of 
the Naval Postgraduate School succeeded in multicasting an extended class over the 
Internet (Emswiler, 1995). Her case study involved multicasting Dr. Richard Hamming’s 
course, “The Art of Doing Science and Engineering; Learning to Learn,” three times a 
week for an entire academic quarter. Emswiler correctly pointed out that storir; -md 
accessing digital recordings of past lectures and conferences is the next step ie 
evolution of this technology. 

B. MOTIVATION 

1. What is the Importance of Distance Learning and the MBone? 

“The organization that learns fastest will survive” (Senge, 1990). This philosophy 
is often forgotten in a cost-cutting era that continuously attempts to do more with less. 
When an organization is facing shrinking budgets and increasing costs, training programs 
are often the first to receive cuts. Training is also set aside when operational 
commitments take students away from local training centers. Due to widespread 
geographic dispersion, military personnel often fall victim to the philosophy of “I’ll go to 
the class when I get back from deplo 5 mient.” Distance education is intended to provide an 
alternative to the usual requirement of a student’s physical presence at school for tr ainin g 
If successful, distance education can reduce training budget expenditures reducing the 
need for travel. 
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The MBone, using the existing Internet infrastructure, provides an interactive way 
to teach and learn. MBone software is economical (the tools are free). It can be used to 
provide real content today and software capabilities continue to gain strength. Applied to 
distance learning, the MBone provides geographically remote students the ability to 
economically and dynamically interact with the teachers and other students using audio, 
video, and other protocol streams. The convergence of all types of information content on 
the Web means that Internet access has become a crucial requirement for all organizations 
for the foreseeable future. Multicast and the MBone are the best technical solutions for 
delivering Internet-compatible audio and video. 

2. How does Video Archiving Apply to Distance Learning? 

Distance learning effectiveness improves not only when long distance can be 
overcome, but also when the timing of classes is no longer a limiting factor. Establishing a 
video archive of the classes that are held over the Internet using the MBone can provide a 
means for students to view classes at their convenience. Students on another continent 
will not have to watch the instructor at 3 A.M. in their local time zone. Instead, they can 
watch the lecture when convenient and ask any question using electronic mail. It will 
actually bring the classroom to the student anytime it is necessary (Emswiler, 1995). 

Internet-based distance learning is not a panacea. Significant human-factors and 
other issues exist regarding pedagogy, effectiveness and ease of use (Gabrino, 94). We do 
not explicitly address those issues in this thesis. Rather, we focus on the technical 
feasibility of recording and distributing digitally archived network-accessible audio/video. 
Further work is needed to maximize the effectiveness of this new medium. 
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C. THESIS ORGANIZATION 


This thesis is organized into the following chapters. Chapter 11 discusses the 
background of this work and other research related to distance learning, the MBone, and 
video archiving. Chapter HI provides a short synopsis of the problems examined in this 
thesis and applications of the results. Chapter IV examines the protocol and payload types 
used for digitizing the desired lectures and conferences. Chapter V explores the methods 
used for building and accessing the archive. Chapter VI shows tht < iperimental results of 
this research. Chapter VII summarizes the conclusions dravra from this work and 
provides recommendations for future work. 

Appendices have been provided for further clarification of concepts addressed in 
this thesis. Appendix A is a glossary of terms used in this thesis. Appendbc B provides the 
HTML and perl Web scripts that are used during video retrieval. Appendix C is an 
instruction set for installing and operating the tools used for video storage and retrieval. 
Appendix D shows two recent articles that detail MBone and Web content work that is 
continuing at NFS. 
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II. BACKGROUND AND RELATED WORK 


A. INTRODUCTION 

This chapter examines pertinent background work and continuing research in 
distance education and the Multicast Backbone (MBone). A short summary of each study 
is provided to explain how they relate to this thesis. 

B. BACKGROUND 

1. Distance Education 

In order to understand the possible applications of the Multicast Backbone and 

video archiving, the term distance education or distance learning must be defined. 

Distance education is a special application of telecommunications to 
teaching and learning situations in which learners are geographically 
separated fi-om teachers, and both depend on electronic devices to 
communicate (Keegan, 1983). 

Distance education can thus be seen as something as simple as a correspondence course 
offered through electronic mail or something as complex as interactive video 
teleconferencing via satellite. 

Distance education does have its limits. Understanding when a distance education 
approach might work is crucial to any implementation. Applications that require extensive 
hands-on training are not the best candidates for distance learning. Yet something like 
‘Math for Marines” (a correspondence course) might easily be taught using distance 
education. The list in Figure 2.1 outlines general situations when a distance education 
approach can be productively applied. 
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♦Target audience is widely scattered and it is not cost effective or possible to 
have them travel to a central training location. 

♦Content or consistency in deliveiy is so critical that it must be carefully 
controlled for accuracy or correct interpretation. 

♦Content is too dangerous for novices to participate in and distance education 
will allow for familiarization and confidence building prior to the actual 
situation. 

♦Scheduling difficulties arise because the student cannot take extended time 
fi’om other critical missions to attend a normally conducted t raining program. 

♦The expense of conducting live training is cost prohibitive. 

♦There are a limited number of qualified trainers. 

Figure 2.1 Productive applications of a Distance Education approach. (Biggs, 1994) 

2 . Multicast Backbone (MBone) 

Video Teleconferencing (VTC) has been the method chosen for many past 
experiments in distance learning. However, this method requires dedicated transmission 
lines, special proprietary hardware and (usually) a dedicated VTC classroom. While there 
have been several alternative VTC technologies to choose fi’om, all have these costly 
minimum requirements. The biggest question when trying to implement a distance 
learning program is which alternative is the most cost effective. 

Since 1992 a new Internet development known as the Multicast Backbone 
(MBone) has been growing in popularity. The MBone was first used to broadcast the 
March 1992 Internet Engineering Task Force (IETF) conference. Since then, it has been 
used for numerous global presentations. Primarily, the MBone has been used by network 
researchers to collaborate with each other. It offers a number of advantages over standard 
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teleconferencing, which instead joins very few sites with expensive dedicated transmission 
lines. MBone links anyone to the Internet who has a workstation or PC and a high-speed 
connection. The increased flexibility of the MBone has resulted in moves by both NASA 
and DOE to replace teleconferencing with MBone meetings (Kahn, 1994). 

Multicasting gained international attention (and made rock-and-roll history) when 
it was used to carry 20 minutes of the Rolling Stones' "Voodoo Lounge" concert tour. 

The concert was carried to some 200 workstations around the world that were connected 
to the Internet. Another example of its potential was seen at a surgeons' conference at the 
University College in London (UCL). Approximately 100 doctors in London and Sweden 
watched as a surgeon in San Francisco performed a complex liver operation. As he 
operated, viewers asked questions about the procedure (Davies, 1995). The MBone has 
also provided around-the-clock coverage of space shuttle flights. In effect, the MBone 
provides free, many-to-many video teleconferencing over the Internet. 

Specifically, the MBone is a subset of the Internet that is capable of multicasting. 
That is, instead of sending identical multiple sets of packets to each destination (like 
delivery of an electronic mail message with multiple recipients), the network copies each 
packet of information fi'om the source and delivers the packets only to those destinations 
that have requested them. The receivers request the packets by subscribing to particular 
sessions. The receiver must be on a network set up for multicasting to be able to sign up 
for a session. Since multicasting capabilities are not built into much of the Internet, the 
MBone is considered a virtual network. It does use the same physical topology as the 
Internet. However, real-time audio and video packets can require special handling, and 
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therefore are distributed using a network of routers that know what to do with multicast 
packets. 

Van Jacobson and Steven McCanne (of the Information and Computing Science 
Division at the Lawrence Berkeley National Laboratory, LBNL) and Steve Deering (of the 
Xerox Palo Alto Research Center) are three of the principal developers of the MBone. 

The team created the software tools used most during MBone multicast (Kahn, 1994). 
Unlike traditional broadcast methods such as radio or television, the MBone is totally 
interactive. The software created by the development team includes a session directory to 
announce events, a shared virtual piece of paper called whiteboard (wb), a video 
conferencing tool, and an audio tool. The software enables real-time audio-video 
conferencing over the Internet. Participants can interact using text, images and face-to- 
face communication. 

Since its inception MBone conferencing has grown exponentially, with traffic 
doubling about every eight months. Right now, more than 10,000 people in 30 countries 
are using it for collaborative work. "Among scientists," predicts Stewart Loken, who 
heads LBL's Information and Computing Sciences Division, "MBone conferencing will 
become as routine as e-mail. And this will happen much sooner than you think.” (Kahn, 
1995) Despite its steady growth, special routing and bandwidth requirements have made 
the MBone somewhat difficult to access. However, new router software is coming onto 
the market that simplifies connecting to the MBone. MBone connectivity is now possible 
over slower links such as 128 Kbps Frame Relay (Erdogan, 1996), and its use appears 
imminent on 128 Kbps ISDN links (Mihlon, 1996). Other advances in the technology that 
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allow recording and remote playback of MBone sessions are also being researched 
(Holfelder, 1996). This type of approach can allow individuals to watch recorded sessions 
at any time, making the sessions more convenient and accessible to people in different time 
zones. 

Today, no other interactive communications tool has been as successful at 
reaching large numbers of people. Primary reasons for this success include public-domain 
software for multiple platforms, and efficient many-to-many packet delivery using 
multicast. With small advances in hardware and software anyone with a computer and an 
Internet coimection will be able to use the MBone. Says Loken, "On the Internet, I 
believe that 1995 will be to MBone what 1994 was to the World Wide Web. Almost 
unknown right now, Internet videoconferencing is about to become commonplace." 

(Kahn, 1995) It is now 1996 and the MBone continues its rapid growth. Getting 
coimected remains labor intensive, but it is a one-time job. It appears that MBone 
expansion has not crossed over into explosive growth, but the steady exponential increase 
remains impressive. 

C. RELATED RESEARCH 

1. Merci Project: Multimedia European Research Conferencing 
Integration 

The Multimedia European Research Conferencing Integration (MERCI) project is 
a follow-on to the Multimedia Integrated Conferencing for Europe (MICE) project, each 
coordinated by UCL (MERCI, 1996). MICE provided multi-way integrated conferencing 
service between a number of European pilot sites, linking various sites to the appropriate 
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communities in the U.S. MICE demonstrated a range of possible ways to internetwork 
project partners using heterogeneous computing environments. The result was the 
interconnection of up to half a dozen conference rooms, up to a dozen workstations, and 
the employment of conferencing services between them. In September of 1995 the MICE 
project gave way to the Multimedia European Research Conferencing Integration 
(MERCI) project. 

The objective of the MERCI project is to provide all the technology components 
(other than the underlying data network itself) to allow proper deployment of software 
tools for European multimedia collaboration. Figure 2.2 shows how MERCI is making 
improvements to the tools developed during the MICE project from 1992-95. 

♦Better integrated facilities, so more easily used by untrained users 

♦Better capability for higher quality video, audio and shared work space 
facilities 

♦Inter-operable cross-platform support for many systems - UNIX 
workstations, PCS and MACs 

♦Better support for the introduction into and recording of multimedia 
information in conference 

♦ Support for different network technologies - mainly over IP; packet-switched, 
ATM or SMDS and ISDN 

♦Inter-operation between workstations running the multicast Internet and the 
normal CCITT procedures 

♦Facilities for secure conferencing - with easy distribution of keys and 
information 

♦Distributed measurement, monitoring and control 
Figure 2.2 Planned MERCI improvements to MICE project tools. (MERCI, 1996) 
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The expected benefits for the users of the MERCI applications are to set a 
standard of excellence for audio/visual techniques and shared whiteboard in tele-teaching, 
remote consultation of doctors, and many other similar disciplines. Industrial 
organizations are also expected to investigate how businesses can be helped by the 
technology. The details of the MERCI project can be found at 
http://WWW. cs. ucl. ac. uk/mice/merci/merci_desc. html. 

2. Anders Klemets: WWW Media-on-Demand System 

This research shows that supporting the playing of continuous media by using 
external programs controlled by a WWW client is possible (Klemets 1994). Klemets’ 
paper describes the design and implementation of a unicast "Media on Demand" server 
that uses WWW as its user interface. Offered media include audio and video recordings of 
transmissions on the Internet Multicast backbone (MBone), and arbitrary prerecorded 
audio files developed during the MICE project. More information on this research can be 
foxmd at: http://www.itkth.se/~klemets/vatplay.html 

3. Video Mosaic (Vosaic) 

This research addresses the problem of the lack of architectures that encourage the 
efficient reuse of continuous media, such as video and audio (Chen, 1995). The 
researchers propose a continuous media model that extends the architecture of the WWW 
to encompass the dynamic, real-time information space of video and audio. Their new 
WWW browser, Vosaic, short for Video Mosaic, incorporates real-time video and audio 
into standard hypertext pages that are displayed in place. They show that real-time video 
and audio data can be effectively served over the present day Internet with the proper 
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transmission protocol. With that, they have developed a real time protocol called VDP 
that specializes in handling real-time video over the WWW. VDP reduces inter-frame jitter 
and dynamically adapts to the client CPU load and network congestion. The WWW 
server dynamically changes transfer protocols, adapting to the request stream and the 
meta-information in requested documents. More information and the server and browser 
software are available at http://choices.cs.uiuc.edu/Vosaic/Vosaic.html. 

4 . Murat Tamer: Multicast and ATM Network Prerequisites for 
Distance Learning 

The basic problem examined in this thesis is how the Multicast Backbone and the 
audio and video tools can be used effectively for distance education (Tamer, 1996). Here, 
the key to effective use is good audio/video quality through Internet connections with 
simple, cost-effective configurations. The focus will be on showing schools that do not 
have great financial resources how to enter and use the MBone for their own distance 
education programs. This thesis can be found online at: 
http://www.stl.nps.navy.mil/~iirg/tamer/thesis.html 

5. Ridvan Erdogan: Implementation of Multicast and MBone Over 
Frame Relay Networks 

This is a thesis that shows the implementation of the MBone over Monterey 
BayNet for educational purposes (Erdogan, 1996). It documents the need for and the 
necessary reconfiguration of Monterey BayNet sites to join the MBone. It shows that 
MBone over Frame Relay networks is possible and that the current MBone technology 
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provides satisfactory performance even on low-speed (128 Kbps) network connections. 
This thesis can be found online at: http:/AvmvMl.nps.navy.mil/~iirg/erdogcm/thesis.html 

6. Robert Norris and Dave West: The Digital Library Phenomenon: 
Opportunities and Implications for the Naval Service 

This thesis examines the emerging field of work encompassed by the term "Digital 
Library" and offers a plan for developing a Naval Service Digital Library (Norris, West, 
1996). Digital resources such as books, magazines, and videos are all part of this plan. 
Archived MBone easily fits into the Digital Library concept by providing easy to use, 
online video lectures and conferences for educational purposes. 

7. Wieland Holfelder: MBone VCR on Demand Service 

This architecture is a separate project that planned to have a java based client that 
has access to an MBone VCR server over a CORBA compliant protocol and can request 
recordings and playbacks fi'om the server (Holfelder, 1996). The server will and announce 
playbacks so other MBone-participants have access to them. This project is part of 
continuing research into the use of MBone VCR by Wieland Holfelder and his research 
group at the University of Mannheim. 
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III. PROBLEM STATEMENT 

A. INTRODUCTION 

This chapter gives an overview of what pieces of the distance learning puzzle are 
missin g and what software tools can be used to fill in those pieces. The chapter goes on 
to discuss where MBone archiving fits into distance learning and how such an archive 
might be put to use in the Naval Service and the Department of Defense as a whole. 

B. OVERVIEW 

Video conferencing is already widely used for remote participation in meeting and 
classroom settings. With many commercial products available for conducting video 
conferences and video classes over the Internet, it is becoming the communication medium 
of choice for remote participation. The MBone is one of the most-used systems to send 
and receive audio and video over the Internet. The focus of this thesis is to show how to 
store and retrieve multicast sessions using the real-time audio and video tools available 
today, all in an economically feasible way. 

1. Why the MBone? 

While the Multicast Backbone is a fairly new technology, it is already widely used. 
The MBone is well suited to large, distributed presentations. It uses network bandwidth 
efficiently and allows participants to join and leave a conference easily. Remote seminar 
participants can receive audio, video and, in some cases, whiteboard information. 
Additionally, interactive audio communication is possible between the lecturers and 
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remote participants (Rettinger, 1995). Several studies have shown that the MBone can 
support real-time classrooms, thus overcoming the distance issues in distance education 
and remote conferencing (Tamer, 1996). 

2. What is Missing? 

The real-time aspect of the MBone does not eliminate any of the time constraints 
that a traditional classroom setting imposes on its students. Considering the world-wide 
reach of the MBone, time zone differences become a majc otor when scheduling 
multicast sessions. A student on another continent watching an event in the United States 
typically must forego sleep to take part in the event. The main question then becomes: 
Can the tools available today provide archived MBone sessions that can be watched at the 
users convenience? 

C. MULTICAST BACKBONE VIDEO CONFERENCE 
RECORDER (MBONE-VCR) 

The recent development and use of the Real-time Transport Protocol (RTPv2) has 
greatly increased the efficiency of real-time conferencing on the MBone. As this protocol 
is refined further, the MBone will continue to expand and its reach across the globe, 
further reducing the need to be in the same location as a conference or class. 

The MBone VCR was developed as a tool to allow MBone conference members 
and participants to record content for later playback (Holfelder, 1995). This new tool, 
which is compatible with the real-time transport protocol (RTPv2), adds more 
functionality to the set of multicast backbone tools and can aid in the elimination of 
restrictions imposed by time zone differences of remote conference participants. Chapter 
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rv provides a closer look at the MBone VCR. Appendix D provides the instructions 
needed for basic operations of the MBone VCR. 

D. MBONE ARCHIVING AND RETRIEVAL 

The immediate goal of this project was to store the Hamming lecture series using 
the MBone VCR. An archive of those files is being created to allow for two different 
types of retrieval: ftp and real-time streaming. By setting up this archive and allowing a 
remote client to start the playback of any of the recorded sessions, we have attempted to 
remove another obstacle to the acceptance of distance learning as an educational tool. 

One obstacle that has to be overcome for the on-demand rebroadcast of MBone 
sessions is that of resource allocation. Since the MBone has an agreed-upon global 
bandwidth of only 500 Kbps, the number of individuals allowed to play back a session at 
one time will be limited by existing MBone events. In order to avoid the abuse of the 
session playback, the author recommends a single permanently dedicated global MBone 
session for use by the MBone VCR. The retrieval scripts used during playback will check 
for current use of the dedicated session and only start transmitting if the session is unused. 
The scripts will further limit the maximum number of sessions that can be played at one 
time to one global session (ttl=127) and two local campus sessions (ttl=15). There are no 
restrictions on the simultaneous number of file retrievals via ftp (other the by network 
congestion and user patience. Chapter V has a detailed discussion of the retrieval methods 
offered by the results of this research. 
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E. DOD APPLICATIONS OF THE MBONE ARCHIVE 


The applications of an MBone archive go hand-in-hand with those used every day 
for the MBone itself However, the archive adds one step past that of offering a class or 
conference to anyone in any place. It adds the flexibility of viewing the conference at any 
time. The number of individuals involved in formal education and number of conferences 
that require participants to travel to another location are two of the biggest considerations 
when contemplating the applicability of the MBone and the MBone VCR. 

There are large numbers of DoD personnel (both trainees and instructors) involved 
in formal courses of instruction throughout each fiscal year. The costs involved in training 
personnel through a formal instructional environment include travel pay and allowances 
for students and instructors that are not performing regular duties, administrative support 
of students and instructors, and operation and maintenance of training centers. Many of 
the same costs apply to individuals that travel to participate in conferences around the 
globe. 

As the MBone becomes more accepted as a standard for distance education and 
remote conferencing and the inconvenience of viewing classes is lessened, large savings 
can be achieved. Personnel will be able to participate in remote training classes and 
conferences either at the time of the original broadcast or later when it fits into their 
schedule. Thus, for many types of training and conferences, and with pedagogical 
improvements in online class preparation and delivery, we expect the need to be in a 
particular location will be eliminated. 
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F. SUMMARY 


The software tools available today make the idea of a usable MBone archive 
entirely possible and economically supportable. This chapter briefly discusses where the 
idea of MBone archiving comes from, and how it applies to the overall goal of improving 
the quality of distance education. This chapter also shows how the ideas discussed in this 
thesis have possible far-reaching implications, not only in the Naval Service but 
throughout the entire Department of Defense and academic community. 
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IV. DIGITAL TRANSPORT ISSUES 


A. INTRODUCTION 

This chapter briefly outlines the reasons leading to the formation of the AVT WG 
and how the Real-time Transport Protocol (RTPv2) attempts to solve the bandwidth 
issues related to transporting audio and video over the Internet. It also reviews the most 
commonly used MBone tools and describes the features of the MBone VCR. 

B. BACKGROUND 

Due to bandwidth constraints, real-time audio and video over the Internet is a 
difficult proposition. At the same time, teaching a class or holding a meeting over a 
network requires real-time interactivity and adequate picture quality. Private networks 
accomplish this by using proprietary VTC protocols and high-speed dedicated links. The 
Internet is a media shared by millions of users and it cannot easily support the high 
bandwidth required for real-time audio and video. To solve this problem, many 
commercial products made for relative low-bandwidth video conferencing over the 
Internet have recently become available. Even with these products, the limited bandwidth 
of the Internet cannot support the entire potential demand for real-time service. There is a 
real possibility of severe network congestion problems caused by indisciminate use of 
poorly designed real-time tools. Thus the Internet Engineering Task Force (IETF), the 
standardization body of the Internet, saw a need to establish a standard protocol for real¬ 
time data transport. 
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The Audio-Video Transport Working Group (AVT WG) within the BETF has been 
charged with developing a protocol that facilitates the transport of digitized real-time data 
(such as interactive voice and video) over packet-switched networks (i.e. the Internet). 
Through their efforts, the use of live audio and video across networks continues to 
become more and more efficient. In January of 1996 the AVT WG published a Request 
for Comments detailing a real-time transport protocol (RTPv2) that is widely used in the 
software tools available for the MBone. 

C. REAL-TIME TRANSPORT PROTOCOL VERSION 2 (RTPv2) 

The Real-time Transport Protocol (RTPv2) developed by the AVT WG is intended 
to provide standardization of streaming packet header formats (EETF RFC 1889, 1996). 
RTPv2 is intended to support improved end-to-end network transport functionality 
suitable for applications transmitting real-time streams (such as audio, video, or simulation 
data) over multicast or unicast network links. However, RTP does not provide a 
guaranteed quality of service (QoS). Therefore, a separate Real-time Transport Control 
Protocol (RTCP) provides the augmentation needed to monitor the delivery of the data). 
Another issue not addressed by RTP is that of resource reservation. RTCP is sufficient to 
meet quality of service QoS goals during some sessions, but it will not necessarily provide 
support to all of the communication control requirements of any one application. Instead, 
if desired, RTP/RTCP relies on resource reservation protocols for QoS support, which go 
beyond the scope of this thesis. (IETF RFC 1889, 1996) 

RTP and RTCP are designed to be independent of the transport and network 
protocols used in a system. Therefore, as long as the underlying network supports 
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multicast distribution, RTP supports the data transfer. The efforts to make RTP transport 
and network independent will allow its use over many protocols. RTP is even currently in 
experimental use directly over Asynchronous Transfer Mode Adaptaion Layer 5 (AAL 5). 

Analog audio and video sources must be digitally encoded before transmitting 
them using RTP. There is a set of default payload types that are mapped to particular 
audio and video encodings. The set up of the protocol allows sources to emit only a 
single RTP payload type. Currently defined payload types carry either audio or video. 
This allows a participant to separate the reception of audio or video if the network 
bandwidth cannot handle both. Figure 4.1 shows the current encodings that are mapped 
to payload types. 


Audio Payloads 


Video Payloads 

1016 (CELP) 

LPC 

CeUB 

G.721 

MPA 

JPEG 

G.722 

PCMA 

H.261 

GSM 

PCMU 

MPV 

L8 

VDVI 

MP2T 

L16 


nv 


Figure 4.1 AudioA^ideo Encodings Mapped to RTPv2 Payload Types (IETF RFC 


1890,1996) 


Additional payload types can be defined dynamically with the use of conference 
control applications that are separate firom RTP and RTCP. Multiple RTP sessions can be 
used in parallel to send multiple media types. Timing information carried in the RTCP 
packets is used for synchronization (IETF RFC 1890, 1996). This capability is used by 
MBone VCR to synchronize separately stored audio-video streams. 
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D. MULTICAST BACKBONE (MBONE) SOFTWARE TOOLS 

The following sections describe some of the most popular, free MBone 
applications available for use on almost any computing platform. To make use of the 
conferencing tools, a LAN must support IP Multicast and (ideally) be connected to the 
MBone. 

1. Session Directory (sdr) 

The session directory (scb") tool is used to advertise and manage the individual 
MBone sessions. It lists the available sessions, is used to create new sessions, and 
provides detailed additional information on each session that is listed. The session 
directory tool also provides the ftinctionality to launch the appropriate viewing tools 
needed to watch (and listen to) any session listed. The latest versions of sdr have a record 
button that is supported by a separate shell script program (record sessiori) facilitating 
launch of the MBone recording tool, MBone VCR. 

An earlier independently developed session directory (sd) tool is also available 
(Wood, 1996). Currently, sdr use and functionality is much broader that that of sd. 

2. Video Conference (vie) Tool 

The vie video tool, developed at the Lawrence Berkeley National Laboratory 
(LBNL) is used to transmit and receive video over the MBone. It is based on RTPv2 and 
can be used in a point-to-point environment. However, it is primarily intended for use in 
multicast/multiparty conferencing environments, vie is backward compatible with RTPvl 
and can interoperate with both nv (v3.3) (Frederick, 1996) and ivs (v3.3) (Turletti, 1996), 
other video tools developed at separate labs. (McCanne, Jacobson, 1996) 
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vie includes the H.261 video compression algorithm which can achieve frame rates 
2-4 times better than that of previous video tools. This is accomplished using a 
sophisticated compression technique that replenishes only the blocks of the picture that 
change. Using cues from the audio tool, vie also has the ability to switch the active 
viewing window among multiple simultaneous video sources to whichever source is 
speaking. (McCanne, Jacobson, 1996) 

3. Visual Audio Tool (vat) 

The visual audio tool (yat), also developed at LBNL, is a real-time audio 
application. Like vie, it is based on RTPv2 and can be used in a point-to-point 
environment, vat is also primarily intended for multicast/multiparty conferencing 
environments. (Jacobson, McCanne, 1996) 

4. Robust Audio Tool (rat) 

rat is an RTPv2-compliant MBone audio tool, available for SunOS, Solaris, IRIX 
and Windows-95 platforms (UCL, 1996). It is developed by the Department of Computer 
Science, University College London (UCL) in the United Kingdom, rat can interoperate 
with vat v.4.0 and has a packet-loss protection mode using redundant encodings (i.e. 
forward error correction - FEC) which provides enhanced performance during conditions 
of packet loss, rat is similar to existing audio tools (such as vat) but offers the extra 
functionality listed in Figure 4.2. 

We have found that the redundancy feature is very powerful and provides 
significant improvement in audio quality even in conditions of 10% packet loss. The 
addition of FEC on a per-packet basis is offset by rat slightly reducing the default 
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♦Redundancy (packet loss protection) using forward error correction 
(FEC) encodings 

♦Improved statistics 

♦Voice / picture synchronization option 

♦Improved hands-free performance option 

Figure 4.2 Extra Functionality Offered by rat (UCL, 1996) 

sampling rate so that total bandwidth and packets-per-second rate is unchanged (Handley, 
1996). No redundancy compatibility is currently planned with vat due to different internal 
buffering schemes used in each tool. 

5. Shared Whiteboard (yvh) 

The shared whiteboard application can be used as a shared drawing surface which 
can also import, export, and view both plain text and Postscript files (Jacobson, 

McCanne, 1996). wb facilitates non-audio interaction and can be used to reliably 
distribute moderately large postscript copies of a speaker’s slides. Viewers can easily 
watch and listen to the speaker using video and audio while simultaneously viewing the 
slides and annotating questions using wh. 

E. MULTICAST BACKBONE VIDEO CONFERENCE 
RECORDER (MBONE-VCR) 

This application is designed and developed for use on the Internet's Multicast 
Backbone (MBone) (Holfelder, 1995). It reads cached session advertisement data from 
the active session directory tool (sd or sdr) that allows the importing of MBone sessions 
directly to the VCR. A graphical user interface (GUI) is used to control recording and 
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playback of sessions sent over the MBone. The VCR stores these sessions by 
synchronizing different media streams based on information provided by RTP. It also 
permits indexing and random access within recorded sessions. A command language 
enables user-independent MBone VCR programming features, e.g. to schedule recordings 
or playbacks at arbitrary times. RTPv2 information is used during the playback of 
recorded sessions. The MBone VCR sends the audio/video data streams out on a 
multicast network address/port combinations, recovering the original tinung of all the 
media streams included in a session and advertising the same encoding protocols used by 
the original applications from which the data was recorded (Holfelder, 1995). Once 
playback has started, the user views the session with the same tools (e.g vie and rat or vat) 
used in the original multicast session that was recorded. 

Users of the MBone VCR are provided with a GUI that looks like the control 
panel of a standard video cassette recorder. The ease of use provided by this interface 
enables even first-time users to operate the basic MBone VCR fimetions. Another 
important feature of the MBone VCR is that it allows the alteration of the scope (i.e. ttl) 
of the session playback. The user is thus able to determine whether the playback is 
intended for a smaller or larger (e.g. local ttl=15 or global ttl=127) audience than the 
original multicast. Appendix D provides instructions on the operation and use of the 
MBone VCR tool. 

These features of the MBone VCR add significant new functionality to the 
current MBone application software suite. Through the use of the MBone VCR, three 
important benefits are achieved; (1) independence from application-specific details, (2) 
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use of already invented and implemented software tools for playback and (3) off-line 
teleconferencing support, since sessions can be recorded and sent out at a later time 
reaching audiences in various time zones. (Holfelfer, 1995) 

F. SUMMARY 

This chapter summarizes the issues relating to problems transporting audio and 
video from one site to another. It discusses how the bandwidth problem lead to the 
formation of the Audio-Video Transport Working Group (AVT WG) and provides a 
discussion of the Real-time Transport Protocol (RTPv2) the group has developed. Next, 
the chapter goes on to review the features of the most-often-used Multicast Backbone 
tools. This is followed by a discussion of the Muticast Backbone Video Conference 
Recorder (MBone VCR), its features and how it can add to the usefulness of the MBone 
as an educational tool. Chapter VI details the experimental results from the use of these 
tools and Appendix C provides instructions for the basic use of the MBone VCR. 
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V. ARCHIVING / STORAGE / ACCESS ISSUES 


A. INTRODUCTION 

This chapter gives the background of the research documented in this thesis and 
addresses the issues that relate to building an MBone archive. It further describes the two 
types of access planned for the archive. Finally it examines the bandwidth issues related to 
transmitting sessions from the recorded archive. 

B. BACKGROUND 

Originally this research focused on other digital encoding schemes such as MPEG 
1, MPEG 2, and MJPEG. Using these methods gave file sizes on the order of gigabytes 
for a feature length film (Klemets, 1994). Storing a reasonable collection of classes or 
lectures would require massive amounts of storage on expensive disks or in a tertiary 
storage system. Our such storage system is the Data Migration Facility (DMF) (also 
known as the “tape bam”) at NPS. Due to the expense involved with using huge 
magnetic disks or off-site storage facilities, the DMF seemed to be the most economical 
alternative. Except for 1-2 minute delays during the mechanical movement of tapes during 
initial access, the retrieval process would require no special actions by remote users of the 
system. 

The cost of DMF tapes (about $25 per 5 GB tape) reasonably satisfies the 
economical side of the problem. However, for sites that do not have mechanical tape 
stations this was not a feasible solution. Therefore, due to the difficulties managing file 
sizes created by these compression techniques, our focus turned to the use of the MBone 
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recording tools which simply save the packets of data that travel across the network. 
Here, the file sizes depend solely on the amount of bandwidth used in the transmission of 
each session. Lectures can be practically stored on LAN storage disks. Numerous NPS 
lectures comprising a video archive might still utilize the NPS DMF capabilities to 
augment ordinary server storage capacity. 

C. BUILDING AN ARCHIVE 

1. Recording 

The video for this system is recorded using the MBone and the MBone VCR 
discussed in Chapter IV. The three simple steps involved in digitally recording an 
audio/video lecture (that already exists on video tape) are listed in Figure 5.1. 

1. Create an MBone session with a ttl of 15 or less so that it does not go 
beyond the local network. 

2. Begin playing the video tape to be recorded as the input to the MBone 
session. 

3. Record the session on a separate workstation using the MBone VCR. 

Figure 5.1 Simplified steps for digitally recording a video tape session using the 
MBone VCR 

The session files are deposited directly to proper storage area and are ready to be played 
after competion. Appendix C provides a detailed explanation of the basic functions of the 
MBone VCR. Copyright permissions are not necessary for our current efforts since all 
sessions are in the public domain. This remains an important consideration in future work. 
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2. Storage Space 

When considering the storage issues that apply to the MBone archive, the author 
had two main areas of concern. The most prominent question was how much digital 
storage a large archive might use. The second question was what type of storage media 
best supports web-based access to the archive. 

The amount of digital storage space required for a recording is dependent on the 
amount of bandwidth used during the original session broadcast. The MBone has a 
maximum global capacity of 500 Kbps (at the time of this writing), but the standard 
transmission levels used for most sessions is 128 Kbps for video and 64 Kbps for audio. 
We assume that recording each session once (at a frame rate suitable for either local or 
global playback) is a practical solution. Using these numbers we arrive at a transmission 
that uses approximately 200 Kbps (a conservatively high estimate). Since the ultimate 
goal is to use this technology for a lecture-style digital classroom we will assume that each 
session will be a 50-minute lecture. Estimated digital storage requirements are shown in 
Figure 5.2. 

200 Kbps stream * 8 bits/Byte = 25 KBps per second 

25 KBps * 60 seconds/minute = 1500 KB/minute 

1500 KB/minute =1.5 MB/minute 

1.5 MB/minute * 50 minutes/lecture = 75 MB/lecture, or 

1.5 MB/minute * 60 minutes/hour = 90 MB/hour 
Figure 5.2 Estimated digital storage requirements. 
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Therefore, with a 50 minute lecture, we expect to use 75 MB 5 ^es of space. Using these 
figures and assuming that each academic-quarter course will have about 30 lectures, a 
typical course might use an approximate total of 2.25 GB of storage space. These 
numbers are significantly smaller than the estimates established at the beginning of this 
research using MPEG compression and previous MBone tools. Recent improvements in 
the compression techmques used in the audio and video tools have further decreased the 
required bandwidth while at the same time improving frame rate and image resolution by 
factors of 2-4 times. This translates into less space required to archive the desired MBone 
sessions with acceptable audio/video quality. Experimental results reported in Chapter VI 
indicate that a 30-lecture archive may require just under 2 GB. 

The type of storage media to be used in this system was the second issue to be 
addressed. Several options were examined, including the use of the DMF at NPS, 
CD-ROM or standard magnetic disk storage. This problem has been greatly simplified by 
the increasing efficiency of the compression techniques used by the MBone tools. Since 
the compression of the video and audio has provided for large reductions in file sizes and 
brings them down to manageable levels, individuals might even be able to start recording 
and watching short sessions on their own smaller typical LANs. 

In this project at NPS we purchased a 9 GB hard drive for primaiy storage and 
investigated using the DMF as backup storage space. CD-ROM has a capacity of 650 
MB, which is another possibility for storing the MBone sessions. Using a CD-ROM drive 
with a data transfer capacity of up to 600 KBps will allow distribution of the recorded 
lecture series or conferences to those hosts or networks that have slow outside 
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connections. CD-ROM may also be useful if the MBone VCR application is ported to the 
realm of the PC. Then even individuals with no network connection at all will be able to 
benefit from the content of the MBone. This is a promising area for future work. 

In the end, the issue of what type of storage media to use must primarily be based 
on the type that is available and the purpose of the recordings at the site that is 
establishing an archive. Our site uses the 9 GB hard drive accessed via a standard UNIX- 
based Network File System (NFS) as primary store and the DMF as a backup facility. 

3. Ffle Naming Conventions 

MBone VCR automatically generates a set of control files for each session 
recording. The session is specified in a session file that is named according to the session 
name and appended with a .vcr extension. The session_name. vcr file contains a 
description of the session, the included media and all of the media parameters in plain 
ASCII format. Along with the session file, VCR generates two other files per media in the 
same directory. The filenames for these files are also automatically generated out of the 
session filename, the media protocol and the media number. The first is a data file that 
ends in .rec (e.g. session_name. rec) that contains the raw data placed into the file as 
it is received from the network. The second is an index file that ends in .idx (e.g. 
session_naine. idx) that contains one fixed-length header per data packet. This RTP 
header holds a mapped time stamp generated from information of the data time stamp, 
index information, channel information (e.g. data/session port) and an offset to the 
corresponding data packet in the session_name. rec file (Holfelder, 1995). 
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For example, if a user records a session consisting of one RTF media (such as 

audio) and has a session name of “test” the list of files will be: 

test.vcr 
test_rtp_l.idx 
test_rtp_l.rec 

Recording a session using a second RTF media (such as video) adds the following files: 

test_rtp_2.idx 
test_rtp_2.rec 

The MBone VCR appends _rtp_l for the first media and _rtp_2 for the second media. 
This simply to identifies the two types of media (e.g. audio_rtp_l or video_rtp_2). It has 
nothing to do with the version of the RTF that is used. All media are recorded using 
RTFv2. 

The author has chosen a simple session file naming convention that indicates the 

content and date of each lecture. An example set of all data and index file names that 

goes with a single Hamming Lecture session using audio and video is as follows. 

Hainiaing_l_Apr95 .vcr 
Hamming_l_Apr95_rtp_l.idx 
Hainming_l_Apr95_rtp_l. rec 
Haitiming_l_Apr95_rtp_2. idx 
Hainming_l_Apr95_rtp_2. rec 

This set of files is for the first lecture in the series of Hamming lectures. Care has been 
taken to ensure that when the sessions involve a series of lectures or conference meetings 
that the files are listed in the proper order. Here, the reader can see that the first lecture in 
the series will be listed before the second (Hamming_2_Apr95) all of the way through the 
30th lecture. 
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The limitation of file name lengths that is imposed by DOS PCS was not taken into 
consideration with this naming scheme since (up to this point in time) the VCR is not 
supported by any PC systems. We expect that long self-descriptive filenames under UNIX 
can be mapped to 8-character filenames for DOS or CD-ROM storage with minimal 
difficulty. 

D. ACCESS METHODS 

Making the playback simple enough for MBone beginners is one of the top goals 
of this project. At this time the easiest technology to use is the World Wide Web. The 
web browsers available today have a highly simplified point and click interface, easily 
mastered by millions of users, and most web servers support common gateway interface 
(CGI) programming (Herrmann, 1996). Using the MBone VCR, CGI scripting, and file 
transfer protocol (ftp) the author has implemented two different methods for retrieving the 
recorded MBone sessions. 

1. Web Page / CGI 

This method uses a CGI script written in the perl language (available in Appendix 
B) that identifies the files to be played from a web page selection made by the user. The 
script then launches MBone VCR. The script response that the user sees provides 
directions that the user needs to properly launch the MBone tools on a local workstation. 
This is similar to the approach demonstrated by Anders Klemets in the Media on Demand 
System for WWW (Klemets, 1994). The uniform resource locator (URL) for this page is 
http://wwwAt.kth.se/~klernets/vatplciy.html 
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This method of direct retrieval via the MBone will most likely be used by larger 
sites that have high-speed LANs (e.g. Ethernet or better) and high-speed connections (e.g. 
T-1,1.5 Mbps) to the Internet. The bandwidth that is required here is the same as that 
which is required to watch MBone sessions live. 

Through the use of the web page the user will have several choices for playback 
provided by the CGI script combo-form. User choices include what session is to be 
played, what media the user wants to receive (i.e. audio and video, only audio, or only 
video), what time-to-live (ttl) is to be used (default is local ttl=15), and what time the 
playback is to start (the default is immediately). Once the form is submitted by the user 
the server responds with a message that confirms the user’s choices and tells the user 
what needs to be entered on the local host’s command line to watch the playing session. 
Since the total MBone bandwidth is limited to 500 Kbps, only one user at a time will be 
allowed to play a global session. Users that come in after the session has started will be 
given a message similar to the first telling them what session is currently playing and what 
tools to launch in order to watch it. Important future work includes automating the local 
launch of the MBone tools, perhaps by using Java applets. 

2. FTP 

The ftp method uses a simple web page generated from a listing of compressed .tar 
files that include all files applicable to a particular session recording. The user selects a 
compressed .tar file and transfers that file to his location. Once the file has been 
transferred, the user uncompresses and expands the set of files and manually launches the 
MBone VCR. The user then chooses the set of files to be played by the VCR and watches 
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the session on his local network. In this case the scope of the new multicast session does 
not need to go beyond the user’s local network. 

This method will be used most often when the receiving network does not have an 
outside connection with suitable bandwidth to receive a live MBone transmission, but can 
support the tools either on a single workstation or on the local network. Smaller 
commands and geographically remote sites that do not have good telephone company 
support are perfect candidates for using this method. In this way, sites that cannot view 
multicast MBone content will now be able to see what they have been missing. 

Figure 5.3 shows the UNIX command line entries required to tar/compress the 
MBone VCR session files. Once the files are compressed they can be transferred to the 
archive storage facility for retrieval. Figure 5.4 shows the entries that uncompress and 
untar the files. 


Command 

tar -cvf session_title.tar 
session_ title.vcr 

Description 

Creates the .tar file and adds the 
.vcr file to it 

tar --rvf session_title. tar 

session_ title_rtp_l.idx 

Adds first .idx file to .tar 
file 

tar -rvf session_title.tar 
session_title_rtp_l.rec 

Adds first .rec file to .tar file 

tar -rvf session_title.tar 
session title rtp_2.idx 

Adds second .idx file to .tar file 

tar -rvf session title.tar 
session_title__rtp_2. rec 

Adds second .rec file to .tar file 

gzip session title.tar 

Compresses the tar file 


Figure 5.3 UNIX command line entries to tar/gzip session files 
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Command 

Description 

gunzip session_title.tar.gz 

Uncompresses the .tar file 

tar -xvf session__title.tar 

Extracts the five files from the 


.tar file 


Figure 5.4 UNIX command line entries to untar/gunzip session files 


E. BANDWIDTH REQUIREMENTS 

The definition of bandwidth is the capacity of a communications connection to 
transmit data. Bandwidth can be dedicated to one user or shared among many users. In 
the case of the MBone, the maximum agreed bandwidth shared globally is 500 Kbps. This 
limitation is on a global scale, so this only limits the number of active world-wide sessions 
that can be played at any one time. Since the standard transmission levels of any MBone 
session are decreasing due to improved compression in the tools, several sessions 
(typically 2 or 3) can coexist using the limited capacity. 

This MBone-on-demand system is set up to play only one global session at a time 
so as not to usurp the bandwidth available for the entire MBone community. 

Nevertheless, the number of local broadcasts is limited only by the campus LAN/backbone 
capacity. At NFS, we will limit that to two concurrent local MBone VCR playback 
sessions. Two session (400Kbps) easily fits into the 10 Mbps Ethemet/100 Mbps FDDI 
MBone on campus. Finally, the number of simultaneous ftp transfers is not constrained. 
The actual duration of those transfers depends on the current load on the network. 
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F. SUMMARY 


This chapter reviews the reasons behind the focus of this thesis. It goes on to 
outline the major issues pertinent to building an MBone archive and describes the methods 
used to access such an archive. General considerations regarding bandwidth used for 
transmitting the contents of the recorded MBone sessions are presented. Appendix B 
shows the html and cgi scripts used to establish Web access to the video archive. 
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VI. EXPERIMENTAL RESULTS 


A. INTRODUCTION 

This chapter provides an overview of the experiments that were performed using 
version l.SaOl of the MBone VCR. It then details the results of each attempt to use the 
MBone VCR to record and play MBone sessions. This is followed by an examination of 
the file sizes produced by recording conference session and the results of experiments 
performing each of the two retrieval methods discussed in chapter V. 

B. OVERVIEW 

The testing described in this chapter is accomplished using the MBone VCR’s 
graphical user interface (GUI) and the MBone tools sdr, vat and vie. RTPv2, developed 
by the IETF AVT WG, is the protocol used by the transmitting tools and recorded by the 
MBone VCR. A software bug prevented our recording using rat with PCM redundancy 
enabled. This will be our preferred audio encoding due to significantly improved audio 
performance in the presence of network congestion and packet loss. 

Since the MBone tools are used regularly and have been proven to work, the 
testing focuses on the addition of the MBone VCR to MBone process. The author had 
six goals (listed in Figure 6.1) when conducting the MBone VCR experiments, all intended 
to evaluate the effectiveness of this new combination of software tools. 

Each initial recording experiment consisted of loading the audio and video session 
into the VCR interface and recording for five minutes. 
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♦Broadcasting and recording on the same workstation 
♦Recording between workstations 
♦Recording transmissions from another network 
♦Playing and watching on the same workstation 
♦Playing between workstations 
♦Playing across networks 

Figure 6.1 Experimental Test Goals 

The binary distributions for all of the software application tools {sdr, vie, vat, rat, 
MBone VCR) are each downloaded from one of the many ftp sites that provide the 
MBone tools. The Multimedia Conferencing Applications Archive, supported by UK 
MICE National Support Center (Wood, 1996) is the most comprehensive of those sites. 
Appendix C gives the instructions for downloading and installing the proper tools as well 
as operating the MBone VCR. 

C. RECORDING A SESSION 

The first step in our testing the effectiveness of the MBone VCR is recording an 
MBone session. If the MBone session is broadcast using sd the MBone VCR can load it 
directly. If sdr is used, a corresponding new session must be created using the “create 
new session” function under the VCR session menu. The multicast addresses and port 
numbers (advertised by sdr) must be entered manually (this feature will be added in a 
future VCR version). Once the session is loaded into the VCR, a deposit directory is 
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selected and recording has been enabled on the user’s workstation, recording begins by 
simply clicking on the MBone VCR record button. 

The MBone VCR waits for the first packets of data to arrive via the multicast 
address/port and begins recording. In a separate UNIX shell listing, the files in the target 
directory using the UNIX command Is-la shows the set of files that is created and 
shows that the file size as data is being collected in those files. This process is followed 
for all three of the recording experiments with much the same result. The origin of the 
data did not affect the VCR in any adverse way. In all cases the same set of files is created 
and the files increased in size as the recording time increased. For all experiments we used 
default bandwidth settings for vat PCM audio (64 Kbps) and vie H.261 video (128 Kbps). 

The file sizes differ slightly with the different transmission origins but that can be 
attributed to the packet loss increases as the distance between transmitting workstation 
and receiving workstation increases. File sizes are noticeably smaller when the receiving 
network has a heavy load. This can also be attributed to the quality of signal received by 
the recording workstation. On average, the total amount of data collected in the five files 
for each session is approximately 1.3 MB per minute (just under the capacity of a 3.5" 
floppy diskette) or 6.5 MB per five minute period. Of interest is the fact that this rate 
corresponds to approximately 78 MB/hour, comfortably less than the 90 MB/hour storage 
rate predicted in Figure 5.2. 

D. PLAYING A RECORDED SESSION 

The next step in evaluating the MBone VCR is to play the recorded sessions. 
Playing and watching the recorded sessions is accomplished in one of three ways. The 
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first is to create a new MBone session with sd or scb". Then copy the advertised multicast 
addresses and port numbers and edit the recorded session’s media to match the new 
session (MBone VCR provides an easy way to accomplish this). Pressing the play button 
on the GUI then plays the session. This test was performed on all of the recordings 
mentioned in Section 1 above. 

Feedback from individuals across the country who watched a global rebroadcast of 
a session reported that the video was clear but the audio was not present in the 
transmission. Remote participants watched the session by launching vie and vat from sdr. 
When launched in this maimer, vat is started with the -r synchronization switch. The 
author experienced the same symptoms on the local network and on the same workstation 
that was playing the session, but fixed the lack of audio by launching vat fi'om the UNIX 
command line without the -r switch. A command similar to the following was used: 

vat -f pem -t 127 -I 1 -C "Test Session" 224.2.230.15/65042 
Without the -r, the audio portion of the session was heard clearly. This VCR bug has 
been reported and is expected to be fixed in the near future. No feedback was received 
from anyone outside of the local network once the audio problem was fixed locally. 

Further tests showed that this lengthy command line entry was not needed. Simply 
specifying the tool and the address/port numbers will allow the user to receive the signal. 
The actual command line entry needed is as follows: 

vat 224.2.230.15/65042 

The second technique of playing a recorded session is to create a new MBone 
session by manually setting the multicast addresses and port numbers to match those that 
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were used by the original transmission at the time of recording. Watching each of the 
three rebroadcasts using sdr to launch vie and vat provides the same results as above. As 
long as vat is launched from the command line without the -r synchronization switch, the 
audio is heard. Properly using the -r does not allow vat to receive the data being 
transmitted by the MBone VCR if the -r was not used to transmit the original signal. If 
the -r is used when transmitting the original recorded session, the audio will be heard with 
or without using the -r when receiving the signal transmitted by the MBone VCR. This 
confusing state of affairs will be much simpler when the bug is corrected. 

The third technique of playing the recorded sessions is to simply load a session and 
click on the play button without creating a new session in sdr. The drawback here is that 
no advertisement of the playing session is sent out to the local or global MBone. 

However, if the session is launched locally or from a web page, the exact command line 
entries needed to watch the session with vie and vat are given before play begins. No 
global unadvertised multicasts have been originated using this method, in deference to 
MBone usage conventions (Macedonia, Brutzman, 1994). Locally the session can be 
watched as clearly as the original multicast. This third approach is not recommended for 
normal us and is only documented here for completeness. 

E. RECORDING A COMPLETE LECTURE 

The tests up to this point had shown that the MBone VCR can be used for short 
periods vwthout failing. The next step was to record an entire lecture or conference to 
examine the performance for an extended period of time (1-2 hours). The session that 
was chosen was the video tape of the August 1996 SIGGRAPH Virtual Reality Modeling 


45 



Language (VRML) Special Interest Group (SIG). The video tape was multicast from one 
workstation using vat and vie and recorded on another using the MBone VCR. Again the 
default bandwidth for audio and video were used and the file sizes increased as the 
recording time increased. The tape was slightly longer than two hours and the five files 
created by the MBone VCR totaled slightly less than 156 MB, approximately 75 MB per 
hour of recording. This number is of interest since it shows that and entire lecture series 
(30+ lectures) might fit into less than 2 GB of storage space. 

F. WEB PAGE/CGI SCRIPT LAUNCH 

After testing the MBone VCR, the next step was to test the combo-form 
and perl scripts that let a user select an MBone session from the recordings and 
automatically start the playback of the selected session through the use of a macro 
command file generated by the perl script. The perl scripts and the HTML that generates 
the combo-form can be found in Appendix B. The use of the macro command file is 
explained in detail in Appendix C. The URL for the Web page is 
http://www.stl.nps.navy.mil/~iirg/metiddy/playerJrames.html 

The Web page interface was tested by selecting a session from the drop-down 
menu, selecting a media, giving a playback start time, and giving a session ttl. The submit 
button was then clicked and the results page correctly showed the information that had 
been entered into the form. The macro command file was opened in a text editor to see if 
the proper commands had been entered into it. All of the appropriate commands to launch 
the MBone VCR had been correctly written to the file. 


46 



Next the submit button generated by the first script and the command file itself 
were tested. The Web page returned and error indicating that the script was 
malfunctioning. The syntax of the script was checked and returned no errors. The script 
was then run fi'om the UNIX command line. Doing this showed that the -c option in the 
MBone VCR (which allows the application to be started from the command line using a 
macro command file) was not functioning properly. The MBone VCR was started but the 
macro command file was not read. However, using the “macro” menu option in the 
MBone VCR interface to test the command file showed that it did successfully load and 
play the proper recorded session. Once the -c option in the MBone VCR is functional, the 
automatic playback system is also expected to function. This software bug has also been 
reported. 

G. FTP RETRIEVAL 

The final step in the testing process was to exercise the ftp retrieval method in 
order to ensure the data in the .tar.gz file was not corrupted in the tar/compress 
uncompress/untar process. The file was first transferred from the DMF to the local 
network. Next the commands listed in Figure 5.4 were used to uncompress and untar the 
files. The session was then loaded into the MBone VCR and played over the local 
network. The session was watched on the workstation that was running MBone VCR and 
another workstation on the same network. Both receiving workstations used vat and vie 
launched from the command line. The session was viewed as clearly as before it was 
archived on the DMF. The DMF archive location is on s ir ius. cc. nps. navy.mi 1 
in directory /h/dl/iirg. 
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H. EVALUATION OF RESULTS 


All of the MBone sessions were recorded in three different ways and the three 
methods of playback were attempted on each of the three recorded sessions. The testing 
was performed using the VCR’s GUI and a combination of 5ci^-launched and command- 
line-launched MBone tools. 

In all experimental cases the default transmission rates on the audio and video 
provided a clear reproduction of the original audio/video session. Using the default video 
quality level of 10 during recording seemed to strike the best balance between quality of 
picture and movement during playback. Participants were able to read any slides that the 
instructor or lecturer used and the frame rate was sufficient for meaningful expression of 
gestures. Facial expressions can sometimes be discerned usefully at this frame rate. No 
experiments were conducted using the MBone whiteboard (wb) tool to transmit slides 
since the MBone VCR does not yet support wb. 

The results of the audio/video testing are satisfactory and demonstrate successful 
recording and playback. These various combinations of tests successfully demonstrated all 
of the software test goals listed in Figure 6.1. 

1. SUMMARY 

This chapter provides the results of experimental testing performed using the 
MBone VCR. Each experiment is discussed as it relates to the six goals outlined in the 
overview of the experimental process. The chapter then explains the results attained when 
an entire conference was recorded and the two retrieval methods were tested. The 
chapter ends with an evaluation of the experimental results. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


A. RESEARCH CONCLUSIONS 

The MBone VCR has been successfully implemented on a local basis around the 
NFS campus. Limited success was achieved on a larger scale, however the level of 
success cannot be measured due to the minimal feedback from remote sites. It is easy to 
see that the MBone VCR can help enhance the capabilities of the world-wide multimedia 
teleconference and distance education already taking place on the Multicast Backbone 
(Holfelder, 1995). Further testing and development is needed to better quantify these 
conclusions. 

The video quality of the recordings is not yet clear enough for feature films, but 
sacrificing a small amoimt of quality provides for manageable file sizes. This is extremely 
important when looking at the distance learning concept from an economic standpoint. At 
this point in the use of the MBone VCR, the quality of the recording is only as good as the 
original MBone broadcast. As the MBone tools continue to improve so will the quality of 
the recorded sessions. As a result of this research, the realm of distance education is one 
step closer to being truly independent of time and geographic location. 

B. RECOMMENDATIONS FOR FUTURE WORK 

The technical aspects of research such as this are only part of the story when the 
overall results can affect people’s lives. Once the technology has been proven to work, 
the next step is to look at how it can be integrated into daily life. The whole purpose of 
the concept of distance education is to help people learn. Therefore, research on the 
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human aspect of distance education needs to include a look at how the content of a class 
or conference is best tailored for effective distance delivery. Correcting the few re maining 
bugs in the technical results of this thesis will enable such research. 

While the tests on the MBone VCR were successful, there are several areas that 
could be improved in future versions of the application. Since the MBone tools are 
already available for most PC platforms, the next logical step for the VCR would be to 
port the program to PC operating systems. This would allow even the smallest networks 
that may have high-speed internal connections to download the recorded sessions and play 
them locally (assuming their outside network connections do not support higher speeds). 
This can also open the possibility of putting the recorded sessions on CD-ROM and 
allowing individuals who may have no network connection at all to watch the sessions on 
their own home systems. The numbers of people able to participate in distance education 
programs then begins to grow exponentially. 

Another needed improvement to the MBone VCR is compatibility with the 
redundant audio encodings used in rat. The use of FEC provides notable performance 
enhancement during periods of poor network performance without increasing the required 
bandwidth. We recommend that video archives be recorded using redundancy. 

Several improvements can also be made to the MBone-on-Demand system at NPS. 
Currently the system has no way of restricting the number of sessions playing at one time. 
One piece of fixture work might be to complete a lockfile system limiting the number of 
global multicast sessions so the system does not overrun the whole MBone. The 
Hamming lecture series that was multicast for an entire quarter is ready to be digitally 
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stored osing the redundant encoding in rat (when it is made compatible with MBone 
VCR) and vie. Other additions to the system, such as getting permanently assigned 
multicast addresses and port numbers for a global MBone VCR channel will continue to 
make it easier to use and more readily accessible. 

As with any new software tool, more testing is needed. Playing and recording 
remotely across different networks and different platforms has only begun. Now that the 
VCR tool is here and useable, it can only get better and become more beneficial. 
Important additional work includes automatic local launch of appropriate MBone tools, 
perhaps using Java applets. 

F inall y^ as Seen in “The Digital Library Phenomenon; Opportunities and 
Implications for the Naval Service,” the Naval service can benefit tremendously from 
meeting non-tactical, day-to-day information needs (Norris, West, 1996). The digital 
library is a concept that is catching on quickly throughout today’s educational 
infrastructure. As that concept grows into actual systems, one goal for the educators 
involved can be to incorporate distance educational systems like the MBone-on-Demand 
system discussed in this thesis into the overall infrastructure. We look forward to the day 
when the use of tools such as the MBone VCR is widespread and easy. 
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APPENDIX A: GLOSSARY 


ACM - Association for Computing Machinery: A large and long-standing professional 
organization dedicated to most of the important issues related to computers. 

Anonymous ftp: A log-on convention used by Internet that lets a user retrieve files from 
a file transfer protocol (ftp) server, even though the user may not have an account on that 
server. 

ANSI - American National Standards Institute: The primary standards organization in 
theU.S. 

ATM - Asynchronous Transfer Mode: International standard for cell relay in which 
multiple service types (such as voice, video, or data) are conveyed in fixed-length 
(53-byte) cells. Fixed-length cells allow cell switching to occur in hardware, thereby 
reducing transit delays. ATM is designed to take advantage of high-speed transmission 
media such as fiber optic cable. 

Compression: The art/science of reducing the number of bits required to store and/or 
transmit digital media. Predominant schemes include MPEG 1, MPEG 2, motion JPEG. 
MPEG performs intra-frame compression as well as inter-frame (or differences from 
frame-to-frame) compression. JPEG, which is predominantly a still-image compression 
scheme, performs only intra-frame compression. 

Digitization: The art/science of converting analog video, images, or audio into digital 
format (i.e.. Is and Os) 

Hypertext Markup Language - HTML: The source language for making World Wide 
Web 2D hypermedia pages. HTML not only formats a Web page, but also provides for 
links to other Web pages or documents. 

Hypertext Transfer Protocol - HTTP: The Internet protocol that enables the World 
Wide Web. This is the protocol designed for serving HTML documents. It is a 
client/server-based protocol. 

IEEE - Institute of Electrical and Electronics Engineers: Professional organization 
whose activities include the development of communications and network standards. IEEE 
LAN standards are the predominant LAN standards today. 

IETF - Internet Engineering Task Force: Task force consisting of over 80 working 
groups responsible for developing Internet standards. 
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Internet: Term used to refer to the largest global internetwork, connecting tens of 
thousands of networks worldwide and having a "culture" that focuses on research and 
standardization based on real-life use. Many leading-edge network technologies come 
from the Internet community. The Internet evolved in part from ARPANET. At one time, 
called the DARPA Internet. Not to be confused with the generic term internet. 

internet: Short for internetwork. While an internet is a network that uses the same 
technology (such as TCP/IP), the term "internet" is usually used to refer to a collection of 
such networks interconnected with routers. Not to be confused with the global Internet. 

IP - Internet Protocol: Network layer protocol in the TCP/IP stack offering a 
connectionless-routed internetwork service. IP provides features for addressing, 
type-of-service specification, fragmentation and reassembly, and security. 

IP address: 32-bit address IPv4 (or 128-bit address in IPV6) assigned to hosts using 
TCP/IP. An IPv4 address belongs to one of five classes (A, B, C, D, or E) and is written 
as 4 octets separated with periods (dotted decimal format). Each address consists of a 
network number, an optional subnetwork number, and a host number. The network and 
subnetwork numbers together are used for routing, while the host number is used to 
address an individual host within the network or subnetwork. A subnet mask is used to 
extract network and subnetwork information from the IP address. Also called an Internet 
address or host address. 

IP multicast: Routing technique that allows IP traffic to be propagated from one source 
to many destinations or from many sources to many destinations. Rather than sending 
duplicate packets to each destination, each packet is sent to a multicast group identified by 
a single IP destination group address. Packet replication occurs at routers in a classical 
router-based network. Multicast traffic uses class D IP addresses. 

LAN - Local-Area Network: High-speed, low-error data network covering a relatively 
small geographic area (up to a few thousand meters). LANs connect workstations, 
peripherals, terminals, and other devices in a single building or other geographically 
limited area. LAN standards specify cabling and signaling at the physical and data link 
layers of the OSI model. Ethernet, FDDI, and Token Ring are widely used LAN 
technologies. 

MPEG 1 - Motion Picture Experts Group: Compressed digital video/audio stream. 
MPEG 1 is 1/4 broadcast quality which translates to 352x240 pixels. Typically 
compressed at 1.5 Mbps. Pronounced "m-peg". 

MPEG 2 - Motion Picture Experts Group: Compressed digital video/audio stream. 
MPEG 2 is broadcast quality and translates to 704x480 pixels at 30 frames per (fps) 
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second in North America and 704x576 fps at 25 fps in Europe. Currently a draft standard. 
Typically compressed at higher than 5 Mbps and meant for higher quality/broadcast uses. 

Multicast Backbone (MBone): A virtual network that provides many-to-many global 
network delivery services for applications such as videoconferencing and audio where 
several hosts need to communicate simultaneously. Provides multicast connectivity 
between LANs across the Internet. 

Multicasting: The ability of an application to send a single message to the network and 
have it delivered to multiple recipients at possibly different locations. 

PCM - Pulse-Code Modulatiou: Transmission of analog information in digital form 
through sampling and encoding the samples with a fixed number of bits. Refers to a 
commonly used audio encoding algorithm. 

RFC - Request For Comments: Document series used as the primary means for 
communicating information about the Internet. Most RFCs document protocol 
specifications (e.g. telnet and ftp). A complete index of RFCs is available at 
http://dis. intemic. net/rfc/ 

Rlogin - remote login: Terminal emulation program (similar to telnet) offered in most 
UNIX implementations. Passwords are not encrypted during transmission. 

TCP - Transmission Control Protocol: Connection-oriented transport layer protocol 
that provides reliable fiill-duplex data transmission. TCP is part of the TCP/IP protocol 
suite at the same level as best-effort UDP. 

TCP/IP - Transmission Control Protocol/Intemet Protocol: Common name for the 
suite of protocols developed by the U.S. DoD in the 1970s to support the construction of 
world-wide internetworks. Common protocol suite used throughout the Internet. 

telnet: Standard terminal emulation protocol in the TCP/IP protocol stack, telnet is used 
for remote terminal connection, enabling users to log in to remote systems and use 
resources as if they were connected to a local system. Passwords are not encrypted during 
transmission. 

Time to Live (ttl): A counter used to limit multicast packet lifetimes. A threshold that a 
multicast datagram needs to be forwarded onto a given tunnel. 

Unicasting: One host exchanging packets with another single specific host. 

URL - Uniform Resource Locator: Standardized addressing scheme for identifying 
hypertext documents and other services using a Web browser. 
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Video Teleconferencing (VTC): A two-way electronic form of communication that 
permits two or more people in different locations to engage in face-to-face audio and 
visual communication. Meetings, seminars, and conferences can be conducted as if all 
participants are in the same room. 

Video Teletraining: The use of point-to-point or multi-point teleconferencing to provide 
interactive remote site training. 

WAN - Wide-Area Network: Data communications network that serves users across a 
broad geographic area, often uses transmission services provided by common carriers. 

WWW (Web) - World Wide Web: Large network of Internet servers providing 
hypertext and other services to terminals running client applications such as a Web 
browser. More generally, all information resources available via the Internet. 

Web browser: Hypertext client application (such as Mosaic or Netscape) used to access 
hypertext documents and other services located on innumerable remote servers throughout 
the Web and the Internet. Text-based, graphical user interface (GUI) and 3D graphics 
browsers using the Virtual Reality Modeling Language (VRML) are also available. 
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APPENDIX B: HTML FOR MBONE PLAYER PAGE AND 
CGI/PERL SESSION RETRIEVAL SCRIPTS 


HTML for the MBone Player Page 

This section is the listing of the HTML that produces the combo-form. This 
HTML provides the user interface on the NFS MBone player page. The URL of the Web 
page is http://www.stl.nps.ncivy.mil/~iirg/tiddy/player Jrames.html 

<htnil> 

<head> 

<title> NPS MBone Player Page</title> 

</head> 

<h2 align=center>NPS <i>MBone </i>Playback</h2> 

<center><p> 

<form method=post action="cgi-bin/vcr_input.cgi" 
target="results_window"> 

<table border=10 cellspacing=0 cellpadding=5> 

<caption align=top></caption> 

<tr> 

<th align=center><font size = 4>User Information</font size = 4></th> 
</tr> 

<tr> 

<td align=center> 

<br><input type=text naine=name size=12 value="UserName?"></p></center> 
</td> 

</tr> 

<tr> 

<th align=center><font size = 5>Select a Session</font size = 5</th> 
</tr> 

<tr> 

<td> 

Hairiming Lectures 

<select name=session align=right> 

<option value="l" selected> 1— DD/MM/YY 
<option value="2"> 2— DD/MM/YY 
<option value="3’’> 3— DD/MM/YY 
<option value="4"> 4— DD/MM/YY 
<option value="5"> 5— DD/MM/YY 
<option value=”6"> 6— DD/MM/YY 
<option value="7"> 7— DD/MM/YY 
<option value="8"> 8— DD/MM/YY 
<option value="9"> 9— DD/MM/YY 
<option value="10"> 10— DD/MM/YY 
<option value="ll"> 11— DD/MM/YY 
<option value="12"> 12— DD/MM/YY 
<option value="13"> 13— DD/MM/YY 
<option value="14"> 14— DD/MM/YY 



<option value="15"> 
<option value="16"> 
<option value="17"> 
<option value="18"> 
<option value="19"> 
<option value="20"> 
<option value="21"> 
<option value="22"> 
<option value="23"> 
<option value="24"> 
<option value=”25"> 
<option value="26"> 
<option value="27"> 
<option value="28"> 
<option value="29"> 
<option value="30"> 
<option value="31"> 
</select> 

</td> 

</tr> 


15— DD/MM/YY 

16— DD/MM/YY 

17— DD/MM/YY 

18— DD/MM/YY 

19— DD/MM/YY 

20— DD/MM/YY 

21— DD/MM/YY 

22— DD/MM/YY 

23— DD/MM/YY 

24— DD/MM/YY 

25— DD/MM/YY 

26— DD/MM/YY 

27— DD/MM/YY 

28— DD/MM/YY 

29— DD/MM/YY 

30— DD/MM/YY 
SIGGRAPH VRML SIG 


<tr> 

<td> 

<center>Media Type&#160 &#160 
<select name=media> 

<option selected value="audio_and_video">Audio and Video 
<option value="audio">Audio Only 
<option value="video">Video Only 
</select></center> 

</td> 

</tr> 

<tr> 

<th align=center><input type="submit" value="Submit Playback 
Information"> </th> 

<tr> 

<th align=center><input type="reset" value=''Reset Defaults"></th> 

<tr> 

<th>&#160</th> 

</tr> 

<tr> 

<th align=center><font size = 5> Advanced Options</font size = 5></th> 
</tr> 

<tr> 

<td align=center> 

<align=left><p>Playback Start time (PDT) 

<input type=text name=start_time size=17 value="HH:MM:SS MM/DD/YY"><br> 
If you need help, here's a 

<a href="http://poisson.ecse.rpi.edu/cgi-bin/tzconvert" 
target=’'_top"> 

timezone converter</a>. 

</td> 

</tr> 

<tr> 
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<td align=right> 

<center><p>Multicast time-to-live (ttl) scope 
<br><select name=ttl align=right> 

<option value=”l”>l: local-area network (LAN) 

<option value="15” selected>15: NPS 

campus <option value="32">31: Monterey Bay (approx.) 

<option value=”128”>127;World-wide MBone 
<option value=”171">171: Global audio MBone 
</select> 

</td> 

</tr> 

<tr><td><center> 

You can also download the entire series as .tar files by going to the 
Lecture Series 

<a href="http: //www. stl. nps.navy,mil/'-iirg/tiddy/hamming^archive/" 
target^”results_window"> 

FTP Archive</a>.</center> 

</tr> 


</table> 

</fonn></center> 

<P> 

<P> 

<hr> 

Last update: 12 September 1996 
</body> 

</html> 
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VCR Input Script 


#!/usr/local/bin/perl 
# 

#vcr_input 

# 

# This script takes input from a combination form 

# echos that information on a second Web page and 

# writes the information to a macro command 

# file that will be used by the VCR to play the 

# chosen MBone session. 

# 

# Michael Tiddy <metiddy@nps.navy.mil> 

# 17 Sept. 1996 

# http://WWW.stl.nps.navy,mil/-iirg/tiddy/vcr_input.cgi 

# 

# References: 

# 

# Herrmann, Eric, Teach Yourself CGI Programming with 

# Perl in a Week, first Edition, Sams.net Publishing, 1996. 

# 

# Tiddy, Michael E., Internetworking: Economical Storage 

# and retrieval of Digital Audio and Video for Distance 

# Learning, Master's Thesis, Naval Postgraduate 

# School, Monterey, California, September 1996. 

# 

# Wall, Larry, and Schwartz, Randal L., 

# Programming Perl, O'Reilly & Associates, Inc., 1991. 

# 

# 

# 

# 

push(@INC, "/cgi-bin”); 
require("cgi-lib.pi"); 

require("ctime.pl"); 

&ReadParse(*input); 

#Get the User__name 
$user_name = $input{*name*}; 

$mydate = 'date'; 

if ($input{*start_time*} eq "HH:MM:SS MM/DD/YY") { 

$start = "$mydate"; 

} 

else { 

$start = $input{*start_time*}; 

} 


#Detennine the lecture chosen 

if ($input{* session*} eq "1") { 

$session_name = " Hamming 1_MM/YY"; 

} 
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elsif ($input{* session’} eq "2”) { 

$session_name = "HainirLing2_MM/YY"; 

} 

elsif ($input{’session’} eq ”3") { 

$session__name = ”Hamming3_MM/YY”; 

} 

elsif ($input{’session’} eq ”4”) { 
$session_name = ’’Hainming4__MM/YY’’; 

} 

elsif ($input{’session’} eq "5") { 

$session_naiae = "Hainining5_MM/YY”; 

} 

elsif ($input{’session*} eq ”6”) { 

$session_name = ”Hamitiing6_MM/YY"; 

} 

elsif ($input{’session’} eq "7") { 

$session__name = ”Hainining7__MM/YY"; 

} 

elsif ($input{’session’} eq ”8”) { 
$session_naine = ”Hainming8_MM/YY"; 

} 

elsif ($input{’session’} eq "9”) { 

$session_name = ”Ha]iirning9__MM/YY'’; 

} 

elsif ($input{’session’} eq "10") { 

$session_name = ”HaiimiinglO_MM/YY’*; 

} 

elsif ($input{’session’} eq "11") { 

$session_name = "Haminingll_MM/YY"; 

} 

elsif ($input{’session’} eq "12") { 

$session_naine = "Haminingl2_MM/YY"; 

} 

elsif ($input{’session’} eq "13") { 

$session___name = "Haininingl3___MM/YY"; 

) 

elsif {$input{’session *} eq "14") { 

$session_name = "Hamming 14__MM/YY”; 

} 

elsif ($input{* session’} eq "15") { 

$session_name == "Hamiriingl5_MM/YY"; 

} 

elsif ($input{’session *} eq "16") { 

$session_name = "Hainmingl6_MM/YY"; 

} 

elsif ($input{* session *} eq "17") { 

$session_name = "Hamiriingl7_MM/YY"; 

} 

elsif ($input{’session*} eq "18") { 

$session_name = "Hamming18_MM/YY”; 

} 

elsif ($input{* session’} eq "19") { 

$session__name = "Hammingl9_MM/YY’’; 

} 

elsif ($input{*session’} eq "20") { 

$session_name = "Hamming20_MM/YY"; 

} 

elsif ($input{’session’) eq "21") { 
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$session_name = "Hamining21_MM/yY"; 

} 

elsif ($input{'session'} eq ”22") { 
$session_name = "Hainming22_MM/YY"; 

} 

elsif ($input{'session'} eq "23") { 
$session_naine = "Hainming23_MM/YY"; 

} 

elsif ($input{'session'} eq "24") { 
$session_naine = "Hainming24_MM/YY"; 

} 

elsif ($input{'session'} eq "25") { 
$session_name = "Hainitiing25_MM/YY"; 

} 

elsif ($input{'session'} eq "26") { 
$session_nanie = "Hainming26_MM/YY"; 

} 

elsif ($input{'session'} eq "27") { 
$session_name = "Hamming27_MM/YY"; 

} 

elsif ($input{'session'} eq "28") { 
$session_name = "Hainming28_MM/YY"; 

} 

elsif ($input{'session'} eq "29") { 
$session_name = "Hamiaing29_MM/YY"; 

} 

elsif ($input{'session'} eq "30") { 

$session_name = "Haitiming30_MM/Yy"; 

} 

elsif ($input{'session'} eq "31") { 

$session_naine = "SIGGRAPH_VRML_SIG"; 

} 


#get requested ttl from combo-form user input 
$session_ttl = $input{'ttl'}; 

#get requested media types 
$media_type = $input{'media'}; 
if ($input{'media'} eq "audio") 

{$tooll = "vat 224.2.222.204\/29366 \&" 
$tool2 = "No video tool"; 

} 

elsif ($input{'media'} eq "video") 

{$tooll = "No audio tool"; 

$tool2 = "vie 224.2.170.70\/65114 \&"; 

} 

elsif ($input{'media') eq "audio_and_video") 
{$tooll = "vat 224.2.222.204\/29366 \&" 
$tool2 = "vie 224.2.170.70\/65114 \&"; 

} 


print "Content-type: text/html\n\n"; 
print"<html>\n"; 
print"<head>\n"; 

print"<title> NPS MBone Player Page</title>\n 

print"</head>\n''; 

print"<body>\n"; 
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print”<h2 align=center>NPS <i>MBone </i>Playback</h2>\n"; 
print”<center>\n”; 

print”<table border=5 cellspacing=0 cellpadding=5>\n**; 

print”<tr align=center>\n"; 
print”<td>\n"; 

print"<h2>Hello $user_name.<br>\n”; 
print"It is $mydate.<br>\n”; 

print"This is your playback information!</h2>\n"; 
print"</tr>\n"; 

print"<tr align=left>\n”; 
print"<td>\n"; 
print"<ul>\n”; 

print"<li>You have chosen the following 
session:<br>$session_name<br>\n"; 

print"<li>You have chosen $media_type as your media.<br>\n"; 
print"<li>Your start time is $start PDT.<br>\n”; 
print"<li>Your ttl is $session_ttl<br>\n"; 
print”</ul>\n"; 
print"</tr>\n"; 

print"<tr align=left>\n"; 
print"<td>\n”; 

print"You need to use the following commands to start the proper 
tool(s):<br>\n"; 

print"<ul>\n"; 
print"<li>$tooll <br>\n"; 
print"<li>$tool2 <br>\n"; 
print"</ul>\n"; 
print"</table>\n”; 
print"</center>\n"; 
print"<br>\n"; 

print"<center>\n"; 

print"If all of the information above is correct,<br>\n"; 
print"press the button to launch the playback.<br>\n"; 
print"<form method=post action=\"vcr_start.cgi\">\n"; 
print”<tr>\n”; 

if ($input{*start_time*} eq MM/DD/YY"){ 

print"<th align=center><input type=\"submit\" value=\"Start 
Playing Now\">\n"; 

} 

else { 

print"<th align=center><input type=\"submit\" value=\"Start 
Playing at $start\">\n"; 

} 

print"</th>\n"; 
print"</form>\n"; 
print"</center>\n"; 
print"</body>\n"; 
print"</html>\n"; 

#open vcr macro file 

open (CMD, ">/usr/local/videoData4/play.cmd") || die "can*t open $cmdfn: 
$!\n"; 
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# start playing at $start 

if ($input{*start_time*} eq "HH:MM:SS MM/DD/YY"){ 

print CMD **#play starts immediately, $start\n"; 

} 

else { 

print CMD "at $start\n"; 

} 

# load session 

print CMD "load /usr/local/videoData4/$session_name.vcr\n"; 
#start playing 
print CMD "play\n"; 

# play for 2.0 hours 

print CMD "wait 02:00:00\n"; 

# stop playing 
print CMD **stop\n"; 

# unload $session_name 
print CMD ”unload\n"; 

# quit vcr 

print CMD **quit\n”; 

#close macro command file 
close(CMD); 

exit; 
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VCR Start Script 


#!/usr/local/bin/perl 

# 

#vcr_input 

# 

# This script is triggered by the submit button created by 

# the previous script. The result of this script is the 

# playing of the chosen MBone session. 

# 

# 

# Michael Tiddy <metiddy@nps.navy.inil> 

# 

# 

# 17 Sept. 1996 

# http: / /WWW. stl. nps. navy .mil/-'iirg/tiddy/vcr_input. cgi 

# 

# References: 

# 

# Herrmann, Eric, Teach Yourself CGI Programming with 

# Perl in a Week, first Edition, Sams.net Publishing, 1996. 

# 

# Tiddy, Michael E., Internetworking: Economical Storage 

# and retrieval of Digital Audio and Video for Distance 

# Learning, Master's Thesis, Naval Postgraduate 

# School, Monterey, California, September 1996. 

# 

# Wall, Larry, and Schwartz, Randal L., 

# Programming Perlr O'Reilly & Associates, Inc., 1991. 

# 

# 

# 

# Make cgi interpreterstart looking for libraries and functions 

# your own directory 
push(@INC, "/cgi-bin”); 

require("cgi-lib.pi”); 

#set the path to the VCR executable file 
$vcr = "/usr/local/bin/vcr”; 

#executes the VCR command with the -c option giving the path name to the 
macro #command file 

exec "$vcr -c /usr/local/videoData4/play.cmd 
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APPENDIX C: INSTRUCTIONS FOR BASIC OPERATION OF THE 


MBONE VCR 

This user’s guide has been created using much of the information provided by the 
creator of the MBone VCR in the postscript file that accompanies the actual program. It 
is designed to assist anyone that desires to use the MBone VCR to record or playback a 
multicast session. There are no instructions here for connecting to the MBone or using 
the MBone tools. Information on either of those topics can be found at The MBone 
Information Web available at http://www.best.com/~prince/techinfo/mbone.html 

OVERVIEW OF THE MBONE VCR 

A session recorded by VCR can consist of as many multicast channels as a user 
desires to record. During recording, the MBone VCR Avill synchronize these time-critical 
data streams based on information provided by protocols such as RTPvl or RTPv2 (the 
Real Time Transport Protocol). The MBone VCR does not need to know which particular 
application originates a data stream or what the exact content of the data stream is; it 
suffices that the data stream conforms to one of the supported protocols. 

To play back a recorded session, the MBone VCR sends the data out to the 
network, recovering the original timing and synchronization of all the media streams 
included in this session and using the same network protocols used by the applications 
from which the data was recorded. Therefore users run these application in order to 
watch and/or listen to the data played back by the MBone VCR. 
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The main MBone VCR window tries to imitate the look of a home vcr. The left 


area of the main window gives some status information about the loaded session whereas 
the right area provides a session clock and buttons to control the session. 

GETTING THE TOOLS 

The free MBone tools and the MBone VCR can all be retrieved using ftp from 
ftp://ftp. ucs. ed ac. uk 

The site contains a description as well as an index to the source and binaries for all 
of the available conferencing tools (Wood, 96). Once the tools have been transferred the 
user must unzip and use the tar -xvf function to install them on the local workstation or 
network. Each tool contains a README file help with any further installation 
requirements. 

To use the MBone VCR you will also need TCL version 7.5 and TK version 4.1 
installed in the directory tree above MBone VCR. If the user does not have root 
permission and cannot fully install TCL/TK, the user can set two environment variables via 
the command line or in .cshrc with entries resembling the following; 
setenv TCL_LIBRARY ~/[master directory] 
setenv TK_LIBRARY ~/[master directory] 

The current versions of TCL and TK can be found at ftp://ftp.smli.com/pub/tcl/ 
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USING THE MBONE VCR 






MBoneVGRv1.3a01 


Session Options Speal Record Tools Macro 


No se5s'«in 


mute^unmute; 


nnnnnn 

UUUU-IJIU 


jtKseisutu^$t.r jKwwwcjmisii ..ess.^wja 


ldxmode:gotd start/end 


Idxniedla:* 


Toggle indexcontrol panel 


I S^ods 


Total time: 
0 ms 


Figure C. 1. MBone VCR User Interface 


shows the user interface. 

The following sections describe the basic functions available to the users of the MBone 


VCR. 
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OPEN A SESSION 


If no session is loaded, "No session" is displayed in the status area of the VCR 
window and the media list (below) is empty. To open an existing session one can either 
use the "Open Session..." entry in the "Session" menu or double click on the "No Session" 
label. Change the pathname to the local MBone storage directory and select a session. 
Figure C.2 shows the “Open Session” window. 



Figure C.2. Open Session 
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IMPORT A SESSION FROM THE SESSION DIRECTORY 


This is probably the easiest way to get started. If you have sd running, it creates a 
file . sd_cache in your home directory (you might need to quit and restart sd in order to 
get an updated version of. sd_cache). The MBone VCR can read and interpret this file 
and create a VCR-session out of it. Just click on "Import SD Session" in the "Session" 
menu and choose from one of the sessions. Figure C.3 shows the “Open Session” 
window. VCR will ask you for a filename after you have chosen a session (it creates a 
default filename out of the session name so you might just want to select an appropriate 
directory). Click OK and you are ready to record this session. Since the sessions in sd 
often only include one media, you might need to edit the session to add more media from 
sd-sessions to your VCR-session (see below for more information). If you are using sdr 
you will have to manually create a new VCR session using the same address and port 
numbers as the sdr session you want to record. 
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Import Session from SD 
Last -/.scl_cache update: Thu Aug 2211:28:55 1996 


Sessions: 

. ■;“■;■■■ . 

iSiGGRAPH 9^RML tech SIG 
5IGGRAPH VRML SIG 


a 



Media tist of session: 


"NPS AUV" 


I audio (rat) 224.2.205.190/18574/ 0/16 
I video (vit^ 224.2.205.190/64262/0/16 



import Session 


Dismiss 


Figure C.3. Import Session 

















CREATE A SESSION 


To create a new (empty) session a user can either use the "New Session..." entry in 
the "Session" menu or double click in the empty media list below the "No session" label. 

If you create a session manually, a session name and an optional session description have 
to be specified in the "New Session" window (Figure C.4). The "Max Scope" defines the 
maximum scope for all media included in this session. To add a new media to the session 
click on the "Add Media" button. 

In the "Add Media" window (Figure C.5) a media name and an optional media 
description as well as the multicast address, the port number, the conference id (only 
needed for RTPvl and vat), the protocol (RTF or vat) and the scope for this media need 
to be specified. Specifying a media command which will be used by the "Start Session 
Tools" function in the "Tools" menu to start the appropriate application for this media is 
optional. At the end, a session file name (which has to end with ".VCR") has to be given 
to the session. Clicking on the "Session Filename" button Avill open a file selection box to 
choose a directory and filename. 
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Session Name: 




New Session 




Session Description: 




Max Scope: ^ host O site v' resion v/ cont. 


world 


H5 






Media List; 


i ^ ■ 

i -' 








Add Media 








Session Filename: 


Import Session from SD 


Ok 


Save 


Cancel 


Figure C.4. New Session 
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IMPORT MULTIPLE SESSIONS FROM THE SESSION DIRECTORY 

With the "Import Session from SD" entry in the "Session" menu one can only 
import a single sd session. Sometimes, however, media that belong to one session are 
announced in different sd-sessions. To be able to record such sessions and rather than 
creating a VCR-session "by hand," one can use the "Import Session from SD" button in 
the "New Session" window to compose your VCR-session out of one or more sd-sessions. 
In the "Import Session from SD" window you will get two lists, a session list and a media 
list. These lists include all the sessions and media found in your ~/. sd cache file. The 
media list always displays the media of the selected session. If you select a different 
session, the media list will be updated automatically. 

You can import an entire sd session (which is a session title, a session description, 
a generated session filename and all media supported by VCR) by clicking on the "Get 
Session" button or double clicking on a session entry in the session Ust. You can also only 
import a session title (together with a session description and a generated session 
filename) with the "Get Title" button (or by double clicking with mouse button 2 on a 
session entry in the session fist). Another possibility is to add one or more media from 
sd-sessions to your existing VCR-session. To do this, you can select a media in the media 
list and then click on the "Add Media" button (or just double click on a media entry in the 
media list). 
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EDIT A SESSION OR MEDIA 


After a session is loaded/created, the session name and a list of media is displayed 
in the status area. Double clicking on the session name will have the same effect as the 
"Edit Session..." entry in the "Session" menu. Double clicking on one of the media in the 
media list will have the same effect as the "Edit Media" button in the "Edit Session" 
window (Figure C.6). The “Edit Media” window is shown in Figure C.7. 













Edit Media 


Media Name: 


Media Desc: 


IP Address; 

5224.2.21646 i 

Portnumber: 

[28906" 

i 

Confid: 



Protocol: 

RTP « 1 

Media Command:! 

; « 1 

Scope: 

,, host 

site region ■■ 4/ 1 

Ok 

Cancel 



Figure C.7. Edit Media 
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MUTE A MEDIA 


A single click with the left mouse button in the media list will select a media so it 
can be muted/unmuted with the "mute/unmute" button below the media list. If the media 
is muted, it is shown as "<media>" instead of "media." If more than one media is selected, 
the "mute/unmute" button will toggle the mute state for all selected media according to 
their mute state. Clicking on a media entry with the middle mouse button will toggle its 
mute state, clicking in the media list with the right mouse button will unselect all selected 
media. The mute/unmute interface is shown in Figure C.8. 

Web Content 

audio ‘-^1 

video i I 


mute/unmutel 



Figure C.8. Mute/Unmute Interface 


RECORD A SESSION 

To record a session, you need to enable recording with the "Recording Enabled" 
entry in the "Record" menu (this step is important and easy to forget). By default, MBone 
VCR does not start to record if it does not receive a data signal from any of the media in 
the session. To start recording even when no data is present, select the "Start recording 





without signal" checkbutton in the "Record” menu. To start recording click on the 
"record" button (third button from the left in Figure C.9). Click the "stop" button (fourth 
button from the left in Figure C.9) to stop the recording. In a non-empty session you can 
only append data so you have to go to the very end to continue recording. 


h! ^ 


► i m N 








Figure C.9. MBone VCR Function Buttons 


Note: 

In order to record your own signal, some tools require that the 
MBone VCR runs on a different host than these tools since they do not 
do local loopback of the multicast address/port combinations (e.g. vat 
and vie). Therefore the "Start Session Tools" window from the 
"Session" menu offers an entry field "Start tools on host" that will start 
the tools with an rsh command on the specified remote host. For this 
case it is required that your -/ . rhosts file allow such operations. 

Since MBone VCR does local loopback, you do not need to run it 
on a different host than the session tools if you only want to play a session 
back. In this case you could set the scope to 0 (host) so you won't send out 
any data to the network. 

The "Stop Session Tools" entry in the tools menu will allow you to 
stop the started tools. It will look for the processes in the process table 
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(regardless whether they were started on the local or a remote host) and if 
they still run, it will send them a kill signal to stop. 


PLAY A SESSION 

To play a session back you simply click on the "play" button (third button from the 
right in Figure C.9). In order to listen and/or watch the data you need to run the 
corresponding MBone tools. These can be launched directly from within the MBone VCR 
with the "Start Session Tools" window in the "Tools" menu. If the option "Autostart 
Session Tools" in the "Tools" menu is selected, the "Start Session Tools" window will 
automatically appear when the user plays a session for the first time. 

FAST FORWARD AND REWIND 

To fast forward (ff) or rewind (rew) a session you can click on the "fif' button 
(second from the left in Figure C.9) or the "rew" button (second from the right in Figure 
C.9). The speed with which the session will be forwarded/rewound can be changed with 
the "FF/REW factor.." entry in the "Options" menu. 

RANDOM ACCESS WITH THE SESSION SLIDER 

The slider on the very bottom of the interface (shoAvn in Figure C. 10) enables 
random access within the session. Clicking with the middle mouse button somewhere in 
the slider will forward or rewind the session to this point. Clicking the left mouse button 
on the slider left from the marker will rewind the session one second, clicking the left 
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mouse button right from the marker will forward the session one second. If the right 
mouse button is clicked an5where on the slider the session playback will pause until the 
button is released. At the lower right comer the total length of the session is displayed. 
Clicking in this field will forward to the end of the session. 


Seconds 


Figure C.IO. Random Access Slider 


JTotal 
■ 00 : 09:59 | 


PLAYING AT VARIOUS SPEEDS 

To change the playback speed you can select "double speed" or "half speed" in the 
"Speed" menu. Note that this feature is not available for all data formats. If multiple 
speeds for a format is not supported, you might mute the media to listen/watch at least the 
other media at double/half speed. 


LOOP MODE 

If the "Loop Mode" entry in the "Options" menu is checked during playback, the 
session will start all over from the beginning when it reaches the end. This feature allows 
continuously transmitting a session. 


INDICES 

The MB one VCR provides a number of different indices. Basically there are two 
categories of indices; automatically generated indices (AGI) and user defined indices 
(UDI). 
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AGIs are automatically generated by MBone VCR during recording. Examples for 
AGIs are "next speaker", "next sync unit" or "new format." UDIs can be set by the user 
either during recording or afterwards. There are five levels of UDIs so a user can use 
different levels for different purposes. To get/set/delete indices you can use the "Index 
Control Panel" by clicking on "Toggle indexcontrolpanel". The "Idxmode" menu will 
change the behavior of the leftmost and the rightmost button in the main window so you 
can select which function these buttons actually perform. This portion of the user 
interface is shown in Figure C. 11. 

I dxmodel goto start/end i ldxmedia: j- 

i To ggle indexcontrol panel | 

Figure C. 11. Index Control Interface 

Note: 

Indices are always media specific so you have to specify an index 
media with the "Idxmedia" menu on which the index functions are 
performed. You can always change this media but you won't see indices set 
on one media if you have selected another. 


BLANK SKIP / AUTO BLANK SKIP 

One of the options in the "Idxmode" menu is "blank skip." This feature will skip 
blank gaps of the specified length in the media selected by the "Idxmedia" menu and 
forward the session to the beginning of the next data. "Blank Skip" and "Auto Blank 
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Skip" are basically the same, the only difference is that during playback "Auto Blank Skip" 
will automatically detect and skip blank areas in the media selected by "Idxmedia." 


VCR MACRO COMMANDS 

The VCR macro commands provide limited control to record and playback 
sessions during ofiF-hours or to write macros for demo purposes. The supported 
commands are: 


load 

unload 

play 

rec 

ff 

rew 

stop 

at 

HHrMMzSS 

MM/DD/YY 

wait 

[ [ [HH: ]MM: ]SS] 

speed 

normal 

double 

half 

goto 

end 

start 

secs 

next_index 

idx 

prev_index 

idx 

next_blank 

ms 

prev_blank 

ms 

mute 

media_nb 

(0...nb_of_media“l) 

auto^start 

on I off 

blink 

on I off 

idx^media 

media_nb 

auto_blank 

ms 


loop 

on I off 

rec_enabled 

on I off 

start_rec 

on_signal | no_signal 

f f_rew_f actor 
value 
start_tools 
stop^tools 
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These commands are documented in the VCR man page and can be used in a 
command file passed to the VCR applications by the "-c" command line parameter. A 
macro file can also be read with the "Run Macro File" entry in the "Macro" menu. The 
commands will be executed sequentially, a "wait" command will wait for hh;mm:ss until 
the next command is read, an “at” command (if not too late) will wait until the specified 
time/date. An example for playback might look hke this. 

# load a demo session (recorded earlier) 
load ~/VCR-data/demo.vcr 

# goto position 10 min. 
goto 600 

# start playing 
play 

# play for 5 min. 
wait 5:00 

# stop playing 
stop 

The macro commands can also be used to automatically start recordings at a specific 
time/date as in: 

# load a demo session (created earlier) 
load ~/VCR-data/demo.vcr 

# start the session tools 
start_tools 

# goto end (recording is only allowed at the end!) 
goto end 

# enable recording 
rec_enabled on 

# start recording at 1:45pm on May 20th 1995 
at 13:45:00 05/20/95 

# start recording 
rec 

# record for 1 hour and 30 mins, 
wait 1:30:00 

# stop recording 
stop 

# close the session tools 
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stop_tools 

# quit the MBone VCR 
quit 

Or another example could be to playback sessions of a conference recording at a specific 
time/date as in: 

# no loop mode 
loop off 

# start playing at 12:00pm on May 20th 1995 
at 12:00:00 05/20/95 

# load confl session 
load ~/VCR-data/conf1.VCR 

# start playing 
play 

# play for 1.5 hours 
wait 01:30:00 

# stop playing 
stop 

# unload confl 
unload 

# start playing at 2:00pm on May 20th 1995 
at 14:00:00 05/20/95 

# load conf2 session 
load ~/VCR-data/conf2.VCR 

# start playing 
play 

# play for 1.5 hours 
wait 01:30:00 

# stop playing 
stop 

# quit VCR 
quit 

For example, this macro could be stored in a file confl-2.cmd and than executed by 
running: 

VCR -c confl-2.cmd 
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KNOWN BUGS/SHORTFALLS 


This research used an early version of the MBone VCR thanks to the enthusiastic 
and expert support of Wieland Holfelder. This section delineates the know bugs and some 
of the shortcomings of the MBone VCR that will hopefully be corrected in future versions 
of the tool. 

♦Not compatible with sdr except by manually entering proper address/port 
numbers. 

♦No rat compatibility as of this writing, important for redundant encodings (FEC) 
of audio. 

♦RTF Sender Reports and RTF Receiver Reports not yet implemented. 

♦Whiteboard (wi) not yet supported. 

♦No bandwidth limiting during playback, may be useful in global (ttl=127) 
sessions. 

♦Additional recording is only possible at the end of a session. 

♦Double and half speed not yet supported for all data formats (may not be 
possible). 

♦TCL/TK support should be statically linked in binaries to eliminate need for users 
to download TCL/TK libraries. 
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APPENDIX D. NFS CAMPUS NEWS ARTICLES ABOUT IIRG AND 
CONTENT AND ACCESS WORKSHOP 


September 6,1996 -- Profs, Students Continue MBone Development 

by Dale Kuska 

In the hit movie Back to the Future, Dr. Emmitt Brown took a DeLorean sports car, a few 
odds and ends in his garage, added a little innovation and ingenuity, and created a time machine 
with little money. 

Professors and students here at NPS have accomplished a similar feat. They took a 
connection to the information super-highway, computer hardware, software and equipment that 
already existed on campus, also used some innovation and ingenuity, and created a high-speed 
Internet classroom at a very low cost. 

While we may not be able to travel through time, the classroom does take advantage of 
developing technology, the Multicast Backbone (MBone) which allows NPS to broadcast classes 
over the Internet to destinations all over the world. "We want to use the MBone more and more 
because of its broad applicability across the Internet, the fact that we can access a lot of people," 
said Professor Don Brutzman. "We would like to be able to teach classes here and have them 
accessible to the Navy over the Internet." 

In order to increase development of the MBone, Brutzman says the clear thing to do was 
create a group of professors and students aimed at doing just that. So began the Information 
Infrastructure Research Group (iirg@stl.nps.navy.mil) and one of their first orders of business was 
to create a dedicated MBone classroom. How to do that was a question that needed answering. 

"Our usual answer to a question of, how do you do something,' is to simply do it; so we 
did," explained Brutzman. "We looked around campus to see what was available to us. We 
found a workstation that had a projector capability. We got a network connection into the 
classroom, so that was a start. From then on, it was fairly straightforward stepping through our 
previous lessons learned. We added a camera and wireless microphone. We wanted to make the 
teaching as natural as possible, so we added an overhead transparency screen." 

But alterations to the classroom didn't stop there, added Brutzman. Public Works 
installed a second screen and added another light switch, giving the group more control over the 
lighting. "Again, this is something that didn't cost us any money. We just asked Public Works to 
do something they are here to do and do very well," said Brutzman. 

NPS's video-teleconferencing classrooms offered the IIRG a working model, Brutzman 
said. "We have learned from looking at the distance learning classroom down (in Root) hall, and 
we tried to incorporate what we learned. But we intentionally wanted to use assets that already 
existed here at the school, not spend money, and move forward, and now I think we have a 
working product," he added. 

The IIRG has not only put together a working on-line classroom, but continues 
researching all areas of MBone and network technologies. "It appears we can send over a 
128kbit/sec ISDN line. Marine Corps Maj. Lauren Million's thesis is trying to show that. We now 
can record MBone digitally and put them on-line for retrieval. (Marine Corps Capt.) Mike 
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Tiddy's thesis is showing that. (Turkish navy Lt. j.g.) Murat Tamer's thesis is documenting that 
you can move all this equipment to an auditorium or conference on a wireless link Basic^ly, that 
this is like a mobile classroom because you can pick it up and use it in another location the next 
day. (Turkish navy Lt. j.g.) Ridvan Erdogan's thesis is showing we can send MBone audio and 
video to local schools, even over their relatively slow connection lines. He's worked with the 
county office of education in Salinas and a school in Soledad," explained Brutzman. 

"We've also had a student looking at how we can internetwork the whole Marine Corps 
and Capt. Jim Nierle laid it out in complete detail. That was a very exciting thesis because of the 
possibilities it may bring," he adds. "The main thing is that our thesis projects some what support 
each other, and the group allows us to meet and discuss similar problems, so that we're not trying 
to reinvent the wheel." 

Brutzman feels that internetworking is clearly the wave of the future in the Navy. "When 
a ship pulls in and ties up next to the pier, double-up the lines, hooks up to shore power, hooks up 
to shore telephone, the next thing on their check list ought to be hook up to the shore Internet 
connection. That way the ship's Local Area Network is connected to the global Internet or the 
Navy's Internet. We think it is inevitable that these things are going to emerge," Brutzman 
explained. 

"The best example of that is how we do business right here at NPS. There's probably not 
a person on this campus that isn't impacted positively by our campus network in their everyday 
work. You couldn't rip it out of this campus if you wanted to, it's that powerful. And there's no 
reason to think it won't be equally as powerful and just as useful on Navy ships." 

There are hurdles, however, to make MBone technology accessible to any Sailor. 
Brutzman feels that when Local Area Networks are implemented on ships, the door will be open 
for MBone technology to fleet sailors worldwide, and "we just want to be ready." 


August 30,1996 ~ Web Builders Share "High Technology" Projects, Lessons 
Learned 

by Barbara Honegger 

On August 26, the 13LA Content and Access (ConAcc) Team — a regional network of 
computer engineers, educators, researchers, and librarians - gathered at NPS for a two-day 
"learning workshop" on building content and access on the World Wide Web. The Web is a 
subset of the Internet, the worldwide network of computer networks. 

Despite the imposing name - I3LA stands for Initiative for Information Infrastructure and 
Linkage Applications - members of the all-volunteer ConAcc team stress the informality of their 
working group. 

"The ConAcc Team is really just a way for anyone interested in developing Web content 
and access to learn from and help each other," said Victoria Welbom, head of the Science Library 
at U.C. Santa Cruz and coordinator/facilitator for the group. "We meet once a month, but there's 
never enough time to really get into the specifics of each other's projects," she said. "So we 
decided to get together for a longer period of time for members to 'show and tell' what they've 
been doing ~ which became the workshop." 
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An exciting 'show and tell' it was. Members not only discussed, but in many cases 
demonstrated, their "examplar" web projects, including "Networked Ocean Science Research and 
Education, Monterey Bay"; a mobile, online classroom using a "telemation" vehicle; "A Place of 
Our Own" - a branch of the Santa Cruz library system set aside just for teenagers, to do 
homework and use computers; the Monterey Bay Area Cooperative Library System; and panels 
on reducing barriers to access, how to build user-interactive web pages, curriculum questions and 
Internet trmning for faculty and students. 

"Our members were both pleased and proud," said Welbom. "Attendance was 
impressive- over 40 on the first day and 20 on the second - and we achieved all of our main 
goals; to educate and motivate each other, increase visibility and regional awareness for the 
network, recruit new members, and show how the technology actually works." 

Throughout the woikshop, for instance, presenters were able to project their Web sites 
and home pages "live" onto an overhead screen using an LCD panel, thanks to the efforts of NPS 
professor Don Brutzman and his dedicated team of students who manned the projection booth. 
They also provided a demonstration of "live" audio and video over the Internet using the 
"Multicast Backbone" (Mbone). 

"Don Brutzman is part of the heart and soul of this effort," said Welbom. "Without him, 
none of it would have happened so soon, or nearly so well." 

I3LA and its three teams — network design, education and content-access — formed two 
years ago when Pacific Bell agreed to provide fi’ee wiring into schools, research labs and libraries 
in Monterey and Santa Cruz Counties and two years of free telephone service for Internet users at 
the wired sites. Local institutions were quick to take advantage of this California Research and 
Education Network (CALREN) agreement, creating a regional network connecting K-12 schools, 
colleges, universities, museums, libraries, government agencies and research institutions in the 
two-county area. 

So far, the regional network, called Monterey BayNet, has connected most users around 
the common theme of environmental and ocean science, providing full Internet access via text, 
hypertext, multimedia, audio and video. Forty five schools, libraries and colleges now have 
medium-speed links, and ten universities and research institutions high-speed connections, in the 
two counties. 

"Although the initial, and therefore most developed, focus has been on science and ocean 
topics," said Welbom, "it is just that, a focus. It's not a limitation. People are free to use the 
Internet, individually or in teams, to look at anything they want to." 

"This broad-based, collaborative effort teams education, science, business and government 
to fundamentally improve our schools," said Bmtzman, a key member of all three I3LA teams. 
"Now that the connectivity is there, our mission is to promote practical uses for the network, and 
to serve users, creators and managers of data and information by facilitating access, building 
content, evaluating resources and maintaining collection." 

The broad reach of the regional network can be seen from the list of workshop attendees 
and participants, which included representatives from UCSC; NPS; DLI; CSU; MIIS; Cabrillo 
College; AMBAG; Monterey County; San Juan Batista, Carmel, Santa Cruz County and 
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Monterey Bay Area Cooperative libraries; PRC; MBARI; the Monterey Bay Aquarium; the 
Monterey Bay National Marine Sanctuary; Moss Landing Marine Labs; Santa Cruz County OflBce 
of Education; Monterey Bay Online; and The Creative Edge. 

According to Brutzman, "people" challenges have been and continue to be as important as 
technical ones in creating, building and maintaining the regional Internet system. 

"One of our mottos is, 'Technical problems have technical solutions, and people problems 
have people solutions,"' he said. "Our goal is to make the high-tech Internet available and useful 
to real people in real jobs, every day." 

In a few weeks, the job of maintaining the network may become a lot harder. As of 
October 1, the two-year CALREN agreement under which Pac Bell provided free wiring and 
phone time expires. 

"We're at a very exciting junction after two years of free connectivity," said Bruzman. 
"We're going to have to find sustainable ways of keeping the schools coimected. And now that 
we have a network, that's more important than ever." Anyone interested in joining the Content 
and Access Team, or with ideas about how to keep the network vital and growing, is invited to 
contact Welbom at 459-2816, or e-mail <welbom@cats.uscs.edu> or <i31a_conacc@mbari.org>. 
More information about the workshop is available at: 

<http.7/www.stl.nps.navy.mil/~brutzman/workshop.html>. And if you missed the workshop, you 
can still see the "live" audio and visual MBone in operation by dropping by Root Hall Room 204 
this Saturday, Sept. 14, Discovery Day, between 10 a m. and 3 p.m. 


92 



LIST OF REFERENCES 


Biggs, Christopher H., Distance Education: A Case Study with Applications for DoD 
ard the Marine Corps, Master’s Thesis, Naval Postgraduate School, Monterey California, 
June 1994. 

Brutzman, Don and Emswiler, T., ‘MBone Unplugged,” online home page. Naval 
Postgraduate School, Monterey California, August 1995. Available at 
http://www. stl. nps. navy, mil/'^brutzman/unplugged html 

Chen, Zhigang, and others, “Real Time Video and Audio in the World Wide Web,” paper 
presented at the Fourth International World Wide Web Conference, December 11-14, 
1995. Available at http://choices. cs. uiuc. edu/Papers/New/vosaic/vosaic. html 

Davies, Bruce, “Lab’s Connection to the MBone Wins ‘95 R&D 100 Award,” LBL 
Currents, online magazine, July 1995. Available at 
http:/Avww. Ibl. bov/ICSD/MBONE/current.html 

Emswiler, Tracey, Internetworking: Worldwide Multicast of the Hamming Lectures for 
Distance Learning, Master’s Thesis, Naval Postgraduate School, Monterey California, 
September 1995. 

Erdogan, Ridvan, Internetworking: Using Global ATM Networks for Live Multicast 
Audio/Video Distribution, Master’s Thesis, Naval Postgraduate School, Monterey 
California, September 1996. Available at 
http: //WWW. stl. nps. navy. mil/~iirg/erdogan/thesis. html 

Frederic, Ron, Network Video Conferencing Tool ftp Site, April 1996. Available at 
_^;//parcftp.xerox. com/pub/net-research/nv-3.3beta/ 

Gambrino, John R., An Analysis of Internet’s MBone: A Media Choice Perspective, 
Master’s Thesis, Naval Naval Postgraduate School, Monterey California, September 

1994. 

Handley, Mark, conversation with Don Brutzman at SIGCOMM ‘96, Stanford California, 
27 August 1996. 

Herrmann, Eric, Teach Yourself CGI Programming with Perl in a Week, first edition, 
Sams.net Publishing, 1996. 

Holfelder, Wieland, “MBone VCR - Video Conference Recording on the MBone,” paper 
presented at the Third ACM Conference on Mutimedia, ACM, San Francisco California, 

1995. 


93 



Holfelder, Wieland, “The MBone VCR Page,” online home page for the MBone VCR, a 
Video Conference Recorder for the MBone, September 1996. Available at 
http://WWW. informatik. uni-mcmnheim. de/~whd/mbom-vcr/ 

Honegger, Barbara, “Web Builders Share ‘High Technology’ Projects, Lessons Learned,” 
Campus News, vol. 3, no. 34, 30 August, 1996. 

Information Infrastructure Research Group (ERG), online home page, September 1996. 
Available at http://www.stl.nps.navy.mil/'-^iirg/ 

Internet Engineering Task Force (IETF) Request For Comments (RFC) 1889, RTF: A 
Transport Protocol for Real-Time Applications, by Schul 2 ainne, H. and others, January 
1996. Available at ftp://ds.intemic.net/rfc/rfcl889.txt 

Internet Engineering Task Force (IETF) Request For Comments (RFC) 1890, RTF: 
Profile for Audio and Video Conferences with Minimal Control, by. and others, January 
1996. Available at ftp://ds.intemic.net/rfc/rfcl890.txt 

Jacobson, Van and McCanne, Steven, “wb - LBNL Whiteboard Tool ” online home page, 
September 1996. PssizA'^QdXhttp://www-nrg.ee.lbl.gOiv/wh/ 

Jacobson, Van and McCaime, Steven, “vat - LBNL Audio Conferencing Tool,” online 
home page, September 1996. Available at http://www-nrg.ee.lbl.gov/vat/ 

Kahn, Jeffery, “Building the Internet’s MBone: LBL’s Van Jacobson a Principal 
Architect,” LBL Science Articles Archive, December 1994. Available at 
http: //WWW. Ibl. bov/science-Articles/Archive/MBONE-van-jacobson.html 

Kahn, Jeffery, “MBone — Communications for the Next Millennium,” LBL Highlights, 
online magazine, July 1995. Available at http://www.lbl.bov/ICSD/MBONE/ 

Keegan, Desmond J., “On Defining Distance Education,” International Perspectives, 
1983. 

Klemets, Anders, “The Design and Implementation of a Media on Demand System for 
WWW,” First International Conference on the World Wide Web: Conference 
Proceedings, May 1994. Available at http://www.it.kth.se/'-klemets/www.html 

Kumar, Vinay, “The MBone Information Web,” online home page, supported by ICAST 
Communiciations Inc., August 1996. Available at 
http://www. best. com/~prince/techinfo/mbone. html 


94 




Kuska, Dale, ‘Trofs, Students Continue MBone Development,” Campus News, vol. 3 no. 
35,6 September 1996. 

Macedonia, M. R. and Brutzman, D. P., ‘MBone Provides Audio and Video Across the 
Internet,”/£££ Computer, vol. 27 no. 4, April 1994. 

McCarme, Steven and Jacobson, Van, “vie - Video Conferencing Tool,” online home 
page, September 1996. Available at http://www-nrg.ee.lbl.gov/vic/ 

Mihlon, Lauren R., Internetworking: Extending Lan Connectivity Using ISDN, Master’s 
Thesis, Naval Postgraduate School, Monterey California, September 1996. Available at 
http: //WWW. stl. nps. navy. mil/~iirg/mihlon/thesis. html 

Norris, R. E., and West, D. The Digital Library Phenomenon: Opportunities and 
Implications for the Naval Service, Master’s Thesis, Naval Postgraduate School, 
Monterey California, June 1996. 

Partridge, Crmg, Gigabit Networking, PiAdASorCNiQ^ey, \99A. 

Progressive Networks, “Real Audio,” online home page, June 1996. Available at 
http://WWW. realaudio. com 

Rangan, P. Venkat; Vin, H.M. and Ramanathan, S., “Designing an On-Demand 
Multimedia Service,” IEEE Communications, vol. 30 no. 7, July 1992, pp. 20-25. 

Rettinger, Leigh Anne, Desktop Videoconferencing: Technology and Use for Remote 
Seminar Delivery, Master’s Thesis, North Carolina State University, Raleigh, North 
Carolina, July 1995. Available at 

http://www2. nesu. edu/eos/service/ece/project/succeedJnfo/larettin/thesis/abs. html 

Senge, Peter, The Fifth Discipline: The Art and Practice of the Learning Organization, 
Doubleday, 1990. 

Tamer, Murat, Internetworking: Multicast and ATM Network Prerequisites for Distance 
Learning, Master’s Thesis, Naval Postgraduate School, Monterey California, September 
1996. Available at http://www. stl. nps. navy. mil/~iirg/tamer/thesis. html 

Turletti, Thierry, “IVS Home Page,” online home page, September 1996. Available at 
http://zenon.inria.fr:8003/rodeo/personnel/Thierry.Turletti/ivs.html 

University College London (UCL), “The RAT (Robust-Audio Tool) Home Page,” online 
home page, September 1996. Available at http://www-mice.cs.ucl.ac.uk/mice/rat/ 


95 



Wall, Larry, and Schwartz, Randal L., Programming Perl, O’Reilly & Associates, Inc., 
1991. 

Wood, Graeme, “The Multimedia Conferencing Applications Archive,” online home page 
for the UK MICE National Support Center, September 1996. Available at 
http://ugwww. ucs. ed. ac. uk/mice/archive/ 


96 



INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center.2 

Cameron Station 

Alexandria, Virginia 22304-6145 

2. Dudley Knox Library, Code 52.2 

Naval Postgraduate School 

Monterey, CA 93943-5101 

3. Director, Training and Education.1 

MCCDC, Code C46 

1019 Elliot Road 
Quantico,VA 22134-5027 

4. Director, Marine Corps Research Center.2 

MCCDC, Code C40RC 

2040 Broadway Street 
Quantico, VA 22134-5107 

5. Director, Studies and Analysis Division.1 

MCCDC, Code C45 

3300 Russell Road 
Quantico, VA 22134-5130 

6. Don Brutzman, Code UW/Br. 4 

Naval Postgraduate School 

Monterey, CA 93943-5101 

7. Hemant Bhargava, Code SM/Bh.1 

Naval Postgraduate School 

Monterey, CA 93943-5101 

8. Rex Buddenberg, Code SM/Bu.1 

Naval Postgraduate School 

Monterey, CA 93943-5101 

9. Michael E. Tiddy. 2 

6261 Strasbourg Dr. 

Corpus Christi, TX 78414 

10. Dipl. Wirtsch. Inf Wieland Holfelder.1 

University of Mannheim 

Praktische Informatik IV 
L 15,16 

D-68131 Mannheim, Germany 


97 













11. Dr. Jim Eagle, Chair, Code UW.1 

Naval Postgraduate School 

Monterey, California 93943-5101 

12. Dr. James C. Emery, Code 05. 1 

Naval Postgraduate School 

Monterey, California 93943-5101 

13. Dr. Reuben Harris, Chair, Code SM/Ha. 1 

Naval Postgraduate School 

Monterey, California 93943-5101 

14. Dr. Ted Lewis, Chair, Code CS. 1 

Naval Postgraduate School 

Monterey, California 93943-5101 

15. Don McGregor, Code CC.1 

Naval Postgraduate School 

Monterey, California 93943-5101 

16. Dave Norman, Code 51. 1 

Director, W.R. Church Computer Center 

Naval Postgraduate School 
Monterey, California 93943-5101 

17. Gary Porter, Code CC. 1 

Naval Postgraduate School 

Monterey, California 93943-5101 

18. Dr. Maxine Reneker, Code 013. 1 

Director, Dudley Knox Library 

Naval Postgraduate School 
Monterey, California 93943-5101 

19. Terry Williams, Code CC. 1 

Naval Postgraduate School 

Monterey, CA 93943-5101 

20. CAPT George Zolla, USN, Ret. 1 

Dudley Knox Library 

Naval Postgraduate School 
Monterey, California 93943-5101 


98 












21. Dr. Marti Atkinson...1 

University of California Santa Cruz 

CIS/CE Board Office 
225 Applied Sciences 
Santa Cruz, California 95064 

22. Roland Baker.1 

Santa Cruz County Office of Education 

Media and Technology Services 
809 Bay Avenue 
Capitola, California 95010 

23. Lt Col Bill Barattino, Code JEEA.1 

Advanced Communications Technology Department 

Center for Systems Engineering 

Defense Information Systems Agency (DIS A) 

10701 Parkridge Blvd 
Reston, VA 22091 

24. Dr. Carl R. Berman, Jr.1 

Office of the Provost 

CSU Monterey Bay 
100 Campus Center 
Seaside CA 93955-8001 


25. Bill Brutzman.1 

3 South Kingman Road 

South Orange, New Jersey 07079 

26. Jeff Bryant.1 

Monterey Bay Aquarium 

886 Cannery Row 
Monterey, California 93940 

27. Dr. Rudy Darken, Code CS\Da.1 

Naval Postgraduate School 

Monterey, CA 93943-5101 

28. Angela Sasse.1 

Project Manager 

Department of Computer Science 
University College London 
Gower Street 
London WC1E6BT 


99 











29. Bruce Gritton.1 

Monterey Bay Aquarium Research Institute (MBARI) 

160 Central Ave 

Pacific Grove, California 93950 

30. Dr. Harold Hawkins.1 

Office of Naval Research 

Cognitive & Neural S&T Division 
Program Officer 
Attn; ONR 341 

800 North Quincy Street, Ballston Tower One 
Arlington, VA 22217-5660 

31. Dr. G. Ross Heath.1 

Executive Director 

Monterey Bay Aquarium Research Institute 
P.O. Box 628 

Moss Landing, California 95039-0628 

32. Jack Linthicum.1 

Technical Information Specialist 

New Technology Development Division 
Office of Engineering and Technology 
Federal Communications Commission 
1919 M Street N.W., 

Washington DC 20554 


33. Leigh Anne Rettinger.1 

18070-HNW Cornell Rd. 

Beaverton, OR 97006 

34. Dr. Michael R. Macedonia. 1 


Fraunhofer Center for Research in Computer Graphics, Inc. 

Vice-President for Developing Global Work Environments 
167 Angell Street 
Providence, RI02906 

35. Kam Matray. 1 

Monterey Bay Technology Education Center, 

Monterey Peninsula Unified School District 
PO Box 1031 

Monterey California 93942-1031 


100 










36. Chris May.1 

California State University, Monterey Bay 

100 Campus Center 
Seaside, California 93955-8001 

37. Michael McCann.1 

Monterey Bay Aquarium Research Institute 

P.O. Box 628 

Moss Landing, CA 95039-0628 

38. Dr. Ray McClmn.1 

Moss Landing Marine Laboratories 

P.O. Box 450 

Moss Landing, California 95039 

39. Mike Mellon.1 

Monterey County Office of Education 

Instructional Resources and Technology 
PO Box 80851 

Salinas, California 93912-0851 

40. Emily Routman.1 


Exhibit Developer, San Jose Tech Museum of Innovation 
145 West San Carlos Street 
San Jose, California 95113 


41. Kathy Ruthowski.1 

Editor, NetTeach News 
13102 Weather Vane Way 
Herndon, Virginia 22071-2944 

42.. Diane Siri.1 


County Superintendent of Schools 
Santa Cruz County Office of Education 
809 Bay Avenue 
Capitola, California 95010 

43 David Stihler.1 

Monterey County Information Systems 

1590 Moffett Street 

Salinas, California 93905-3341 


101 











1 


44.. Chris Taylor. 

Director of Computing and Computer Resources (CCR) 

California State University, Monterey Bay 
100 Campus Center 
Seaside, California 93955-8001 

45 Jim Warner. 1 

Network Engineer, University of California Santa Cruz 
CAT S/Network & Telco Services 
11 Communications Bldg 
Santa Cruz, California 95064 

46. Dr. Steve Webster.1 

Director of Education 
Monterey Bay Aquarium 
886 Cannery Row 
Monterey, California 93940 


102 





